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ABSTRACT 



A method and mechanism for automatically correlating a 
device to its appropriate driver and family within a computer 
system utilizing candidate matching. A device tree indicat- 
ing devices coupled to a computer system is available from 
an operating system, Within the device tree are device nodes 
which specify a particular device's name (device name) and 
a property which indicates compatible device names 
(compatible names) to the particular device. Drivers and 
corresponding families for devices can be located in RAM, 
ROM, or in another storage media (such as disk drive). 
Drivers can include a data field indicating a driver name 
indicative of a corresponding device with which they oper- 
ate. Far a particular device, the system constructs a candi- 
date list of drivers by comparing (1) the device name and (2) 
the compatible names from the device tree against all die 
driver names of data fields of all known drivers. The 
candidate list is sorted so that matches by device name and 
proper version number are higher priority. Corresponding 
families are then determined and loaded. The system then 
sequentially attempts installation of the drivers from the 
candidate list to the particular device (based on priority 
order) to determine the ap pro pr iate driver (e.g., probing the 
device using diagnostic operations). Drivers are skipped that 
cause an error or mat do not properly configure the device. 
The process can be repeated for aU devices in the computer 
system. The process is dynamic in that it is operable on boot 
up and upon any system change that allows more drives to 
be recognized. 

22 Chums, 13 Drawing Sheets 
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DYNAMIC DEVICE MATCHING USING In a particular systems, a PQ (Peripheral Component 

DRIVER CANDIDATE LISTS Interconnect) standard is adopted wherein a device driver 

name can be associated with a device. This name can be 
This application is a continuation-in-part of patent appli- placed inside the device* s memory. However, the PCI stan- 
cation Sex. No. 08/435 ,676, which was filed on May 5, 1995, 5 dard does not require that each device provide a name for the 
now U.S. Pat No. 5,630,076 and is entitled; Dynamic its associated driver. Therefore, there is not a guaranteed one 
Device Matching Using Driver Candidate Lists. to one correspondence between a device name and its 

associated driver for ail system devices. If a driver does not 
BACKGROUND OF THE INVENTION provide its own driver name, then the system constructs a 

(1) Field of the Invention 10 P seu <*° namc usin g *c device vender information and also 

The present invention relates to the field of device oper- ? c ^ vcnd * Monnatio11 ™ d 

^vnihTeg^to^ctsof&compXBsysUnL^ device type imgbt correspond to inore than one device. In 

specifically, the present invention relates to the field of ^ a - 1 dnV f r correspond to more than one 

device and driver compatibility within a computer system c ^ce but will only operate wife one device. ITus unfortu- 

for device configuration^ 15 nate case increases the difficulty in properly assigning a 

(2\ Prior Art device to *** ^ What 15 nccded & a mechanism and 

\) or ah method mat overcomes the above problem. The present 

Computer systems are composed of a variety of different invention provides such solution, 

components or "devices" that operate together to form the Accordingly, it is an object of the present invention to 

nsutont systein. Really, some of the devices are supplied M a ^Lnism and m^<>d fee Gently InT^ 

with the computer system initially, such as a central pro- £ vcly con^g a ^stem * ~ 

S^^T™^ 0 ^'^^^^ driver, ft is ^^T^Z^ZHZ 

&e <«mputer system after the uuhal con- ^ ^ ^ ^ £ ^ ^ 

figuration of the system. In any event in the general case, 1^ ^ Qt% OTW¥W r Qtlfc . • ^ ^ . 

~r ■ . „ i . * ^ A 6 ^ mines an appropriate dnver, from among a set of drivers, for 

^device tos an ^sociatcd dnvex tha^ among other * a particulate* of a computer systenL It is also an object 

flmcuons, configures the device and aUows the device to be of a e p«seat invention to^oJthe above for all de^S 

openhle wiftinlne overall sy^en, Drivers are typically of the computer system. It i^yet another object of the prSeTt 

^ *™ DS bCl °^ lm ? the COm P Uto inventionTutihi the above to facilitate cSputer E 

system s memory and when executed will communicate ^^fi,*,™- v^Tvl. , 

j »1 , ^ ^ jT_r I configuring computer systems after a modification thereof 

with the device to properly configure the device for opera- m ^^TZT^i^^uZ „jjL u . " 

. . 777^ waMUU ™ waau "j.**™ « wmai clear within discussions of the present invention Dresented 
communication within the overall system typically includes hereiiL t**^** iuywuwu jracmcu 

input/output (I/O) of information between a device and 35 

another part of the system; this communication includes I/O SUMMARY OF THE INVENTION 

^^*J* ^ "aEE ^^J* Amethod and inechanism are desert 

patent application ^Ser. No 08/435,677, which was filed on correlating a device to its appropriate driver within a com- 
^ y J> ^J** " "^.j**!^. Apparatus for putcr system utilizing candidate rnatching. A device tree 
Handling I/O Requests, and which is hereby incorporated by 40 indicating devices coupled to a computer system is available 
reference. Since installed devices can be altered and since from ^ operating system. WMmi me devia tree are device 
new devices can be inserted into a configured computer nodes which specify a particular device's name (device 

^f^l^f ?**T£i to mc 10 name ) aflda F™P«ty which indicates compatible device 
me proper device for reliable operation of the computer names (compatible iiames) to me partial^ Drivers 

systcnL 45 for devices can be located in RAM, ROM, or in another 

In the past, devices were matched wim their proper driver storage media (such as disk drive). Drivers can include a 

by strict one to one correspondence mat was typically data field indicating a driver name indicative of a corre- 

manuaUy performed by the computer system user. That is to sponding device with which they operate and a data field 

say, the computer system user would alter the contents of a indicating a service category of the family with which they 

system file that was read at computer "boot" and this system 50 belong. In one embodiment, for a particular device, the 

file would contain a list of drivers that the computer system system constructs a candidate list of drivers by comparing 

recognized and would associate a particular driver to a the device name and the compatible names from the device 

particular device according to an inflexible listing. The tree against all the driver names of data fields of all known 

driver first needed to be loaded into the computer system drivers. In addition, the corresponding family code, which 

before the system file was updated by the computer user so 55 provides an interface to the driver code, is determined for 

that the system would recognize the driver. This system is each driver candidate by comparing the service category 

referred to herein as "hard coding" the drivers to their contained in the category information of the driver to a set 

associated devices. While workable in some respects for of family names indicative of the available families. The 

knowledgeable computer users, this system is undesirable candidate list is sorted so that matches by device name and 

for computer users that do not have the know how to 60 proper version number are higher priority. The system then 

perform the proper matching between a given device and its sequentially attempts installation of the drivers from the 

driver or for those that do not know the location of the proper candidate list to the particular device (based on priority 

driver. It would be desirable, then, to provide a mechanism order) to determine the appropriate driver (eg., probing the 

and method for reducing problems associated with config- device using diagnostic operations). Drivers are skipped that 

uring the proper driver with its associated device in a 65 cause an error or that do not properly configure the device, 

computer system. The present invention provides such The process can be repeated for all devices in the computer 

advantageous solution. system. The process is dynamic in that it is operable on boot 
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up and upon any system change that allows more drivers to 
be recognized by the computer system. 

Alternative embodiments of the present invention include, 
in a computer system having a processor coupled to a 
communication bus, a memory unit coupled to the commu- 5 
nication bus, and devices coupled to the communication bus, 
a method fox configuring a particular device of the devices, 
the method comprising the computer implemented steps of: 
reporting a set of device names associated with the particular 
device; scanning a first set of available drivers within the 10 
computer system to determine a second set of drivers 
individually having a driver name that matches with any 
name of the set of device names (including a compatible 
device name); sorting the second set of drivers by a priority 
of compatibility with the particular device; sequentially 15 
attempting installation of individual drivers of the second set 
of drivers with the particular device to determine a first 
matching driver of the second set of drivers that properly 
configures the particular device; and installing the first 
matching driver with the particular device upon an indica- 20 
tion by the step of sequentially attempting installation. 
Embodiments of the present invention include the above and 
wherein the a set of device names associated with the 
particular device comprises a device name of the particular 
device and a set of compatible device names indicating 23 
devices compatible with the particular device. 

Alternative embodiments of the present invention include 
the above and wherein the step of sorting the second set of 
drivers by a priority of compatibility with the particular 
device comprises the computer implemented steps of: sort- 30 
ing the second set of drivers such that an individual driver 
matching with the device name is given higher priority over 
an individual driver wwtrfring with a compatible device 
name of the set of c<>mpatible device names; and sorting the 
second set of driven according to driver version informa- 
tion. Embodiments of the present invention include the 
above and wherein the step of sequentially attempting 
installation comprises the computer implemented steps of: 
probing the particular device with a particular driver of the 
second set of drivers; performing a diagnostic test with 40 
respect to the particular driver and the particular device; and 
reporting a status indicating whether or not the particular 
driver and the particulaT device are compatible. 

Alternative embodiments of the present invention include 45 
the above and further comprising the computer implemented 
steps of: s^mnfng a third set of available drivers within the 
computer system to determine a fourth set of drivers having 
a driver nami> that matrhfts with either the device name or 
any name of the set of compatible names, the forth set larger ^ 
than the second set; and sorting the form set of drivers by a 
priority of compatibility with the particular device; sequen- 
tially attempting installation of individual drivers of the 
forth set of drivers with the particular device to determine a 
second matching driver of the forth set of drivers that 5J 
properly configures die particular device, the second match- 
ing driver being more compatible with the device over the 
first matting driver, removing the first matching driver 
from the particular device; and installing the second match- 
ing driver with the particular device. ^ 

Embodiments of the present invention also include a 
computer system implemented in accordance with the 
above. 

A portion of the disclosure of mis patent document 
contains t™**"* 1 which is subject to copyright protection. 65 
The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent 
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disclosure, as it appears in the Patent and Trademark Office 
patent file or records, but otherwise reserves all copyright or 
mask work rights whatsoever. Copyright Apple Computer, 
Inc. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram illustration of a computer 
system used by embodiments of the present invention. 

FIG. 2 is an illustration of a device tree database of I/O 
devices and communication buses used by the present 
invention. 

FIG. 3 illustrates a relationship between the present 
invention Driver Loader Library (DLL), the Code Fragment 
Manager (CFM), the computer system's operating system 
and the computer system firmware. 

FIG. 4 illustrates information contained in a particular 
device node of the device tree. 

FIG. 5a is an illustration of pertinent sections of a typical 
device driver used by the present invention including data 
section structure. 

FIG. 5b is an illustration of pertinent sections of a typical 
family utilized by one embodiment of the present invention. 

FIG. 6 illustrates relationships of the Device Manager ("a 
generic family**), the ROM, and the DLL of the present 
invention. 

FIG. 7 is an illustration of functionality groups of the DLL 
of the present invention, anrfnrffag loading an installation of 
drivers. 

FIG. 8 illustrates a flow diagram (logic) of a procedure of 
the present invention for performing driver matching against 
a particular device using candidate lists. 

FIG. 9a illustrates a flow dia&am (logic) of procedure of 
the present invention for constructing a candidate list for a 
particular device inHW»d in the device tree database. 

FIG. 9b illustrates a flow diagram (logic) of rxocedureof 
the present invention for determining corresponding fami- 
lies. 

FIG. 9c illustrates a flow diagram (logic) of procedure of 
the present invention for selecting a driver. 

FIG. 10 illustrates a flow diagram (logic) of procedure of 
the present invention for sorting a ranrfiriatc list of a par- 
ticular device indicated in the device tree database. 

FKJ. 11 illustrates a flow diagram (logic) of an alternative 
embodiment of the invention for sequentially applying driv- 
ers of a candidate list to a particular device associated with 
that list to automatically determine an ap propriate driver for 
the particular device. 

DETAILED DESCRIPTION OF THE 
INVENTION 

The present invention includes an apparatus and method 
for automatically determining a driver and corresponding 
family for a particular device coupled within a computer 
system. In the following detailed description of the present 
invention numerous specific details are set forth in order to 
provide a thorough understanding of the present invention. 
However, it will be obvious to one skilled in the art that the 
present invention may be practiced without these specific 
details. In other instances well known methods, procedures, 
components, and circuits have not been described in detail 
as not to unnecessarily obscure aspects of the present 
invention. Some portions of the detailed descriptions which 
follow are presented in terms of procedures and symbolic 
representations of operations on data bits within a computer 
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memory. These procedure descriptions and representations given direction or manner of displacement. It is appreciated 
are the means used by those skilled in the data processing that the computer chassis 110 may include the following 
arts to most effectively convey the substance of their work components of the present invention: the processor 101, the 
to others skilled in the art. Unless specifically stated other- ROM 103, the RAM 102, the data storage device 104, and 
wise as apparent from the following discussion, it is appre- 5 the sigoal input and output communication device 108 and 
dated that throughout the present invention, discussions optionally a hard copy fainting device, 
utilizing terms such as ''processing" or "computing" or IL DEVICE TREE DATABASE 

"calculating" or "determining" or "displaying" or the like, FIG. 2 illustrates a logical representation of a simplified 
refer to the action and processes of a computer system (e.g., and exemplary device tree 10 database recognized by the 
see FIG. 1), or similar electronic computing device, that 10 present invention. This device tree 10 is a database stored in 
manipulates' and transforms data represented as physical computer memory as is a hierarchical tree composed of 
(electronic) quantities within the computer system's regis- device nodes such as noes lOa-10*. This device tree 10 is 
ters and memories into other data similarly represented as constructed during the initialization of the operation system 
physical quantities within the computer system memories or 30 (e.g M during "boot") and may be altered mereafter. A 
registers or other such information storage, transmission or 15 number of different procedures can be used within the 
display devices. present invention to generate a listing of devices coupled 

L COMPUTER SYSTEM within the computer system 120. One such procedure is the 

Procedures of the present invention to be described to IEEE P. 1275 firmware prc**dure that is used by one 
follow operate within the environment of a computer system einbodimcnt of the present invention. The device tree 10 
120 as shown with reference to FIG. 1. An exemplary 20 database begins as a single root node 10a that represents the 
computer system is of the Macintosh line by Apple CPU's memory bus. All I/O buses and attached devices are 
Computer, Inc. of Cupertino, Calif., however any number of assumed to descend from this single root or "node" 10a. 
other commercially available computer systems can effec- Layers descending the device tree 10 database are dependent 
trvety operate the procedures of the present invention and on the operation of devices associated with nodes above 
therefore come within the scope of the present invention. 25 them Buses are parent nodes and devices for the leaf nodes 

Generally, the computer system 120 comprises a bus 100 of the device tree 10. A complete device tree 10 represents 
for communicating information, a central processor (CPU) the device topology of the computer system 20. A bus node 

101 coupled with the bus for processing information and in the device tree represents an I/O address space. Each 
command instructions, a random access memory (RAM) device on a bus operates within the address space supported 

102 coupled with the bus 100 for storing information and 30 by its parent bus. Buses also contain information regarding 
instructions for the central processor 101, a read only interrupts , so that a device can request service from a driver 
memory (ROM) 103 coupled with the bus 100 for storing It is appreciated that drivers of the present invention are 
static information and command instructions for the proces- matched to devices, but not to buses. In the device tree 10, 
sor 101, a data storage device 104 such as a magnetic disk buses can lead to other buses. A node of the device tree 10 
or optical and disk drive coupled with the bus 100 for storing 35 that corresponds to a device is called a "device node." 
information and command instructions, and a display device Devices added to the computer system 120 will be added to 
105 coupled to the bus 100 for displaying information to the the device tree 10 upon initialization of the computer system 
computer user. A portion of the ROM 103 contains "firm- 120. Devices can contain drives, such as the disk drive 104 
ware M utilized by the computer system for performing can store drives in a device driver folder. 

certain system tasks. The computer system's operating sys- 40 The present invention used information described above 
tern software 30 (FIG. 3) can reside in the RAM 102, in the in a Name registry which is essentially a copy of pertinent 
ROM 103 or within both. Portions of the operating system information obtained from the device tree 10 database. 
30 can also reside in other data storage mediums such as the Therefore, discussions herein refer to the name registry 10 
data storage device 104. and the device tree 10 synonymously. 

There is also an alphanumeric input device 106 in the 45 Referring to FIG. 2 and FIG. 3, an exemplary device tree 
system 120 in FIG. 1 including alphanumeric and function 10 mat can be used by the present invention is generated by 
keys coupled to the bus 100 for cemmunicating information firmware 20 upon the initialization of the computer system 
and command selections to the central processor 101, a 120. While a portion of the information contained in the 
cursor control device 107 coupled to the bus for communi- device tree 10 is utilized by the present invention, the actual 
eating user input information and command selections to the x (complete) copy of the device tree 10 as generated by the 
central processor 101 based on hand movement, and an input firmware need to be used. At system imtialization, devices 
and output device 106 coupled to the bus 100 for commu- communicate their presence to firmware 20 which cooper- 
nicating information to and from the computer system 120. ateswith the operating system 30 to constnict the device tree 
The signal generation device 106 includes, as an input 10. Information of the device tree 10 used b y the present 
device, a high speed cornmunication port configured to 55 invention can be constructed under the IEEE P. 1275 Stan- 
receive and transmit information. dard which is well known in the art and is not described 

The display device 105 utilized with the computer system herein. The device tree 10 database can be modified by the 
120 of the present invention may be a liquid crystal device, computer system's operating system 30 from time to time as 
cathode ray tube, or other display device suitable for creat- required or instructed. As will be described further below, 
ing graphic images and alrAanumeric characters recogniz- 60 procedures of one embodiment of the present invention 
able to the user. The cursor control device 107 allows the within a driver loader library (DLL) 45 operate within the 
computer user to dynamically signal the two dimensional environment of a Code fragment Manager 40 (GFM). The 
movement of a visible symbol or cursor on a display screen DLL 45 operation is described in terms of the functionality 
of the display device 105. Many implementations of the described herein. It is readily apparent to one skilled in the 
cursor control device are known in the art including a 65 art that the DLL can be implemented a variety of ways 
trackball, mouse, joystick or special keys on the alphanu- following the teachings of the present invention. The CFM 
meric input device 105 capable of signaling movement of a 40 used by the present invention is described in more detail 
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in a publication entitled Inside the Macintosh "PowerPC sections: (1) a data section 80a; and (2) a code section 806. 

System Software," by Apple Computer, Inc., published by The data section 80a contains a driver description data 

Addison-Wesley Publishing Company, February 1994, (see structure which does contain a "driver name" 80c. This 

specifically chapto three). One of ordinary skill in fee art driver name 80c can be specific to a particular device or can 
would uncUrstand the ndatwiiship tetwee^ the firmware 20, 5 contain a generic name applicable to a dass or group of 

Ac operating ; systen software 30, and the CTM 40 as Evicts. Also contained wSud the driver desmrttondata 

^scribed in the above : cited inference. An embodiment of structure are ( 1) version information regarding the^on of 

the present invention utilizes this relationship shown in FIG. me ^ ^ 80* and also (2) ^c^y informal 

With reference to FIG. 4, each device node 10a-10*of the ?&<^Jn* <* <kyice for which the driver is to be used 

device tree 10 database is presented to the operating system 10 rf y dlsk ^ M ^ discussed 

30 and drivers by associated descriptive pieces of data called mc cate 8 oi y infonnauon is used to select the corre- 
properties that are within each node. A representative device spending family. The driver name 80c of the driver descrip- 
node lOfis illustrated. All device nodes of the device tree 10 tion data structure 80a can be a generic driver name (eg., 

database have a property that indicates the name 50 of the NDRV) in the event the driver is compatible with a number 

particular device (e.g., device name). FIG. 4 illustrates the 15 °f different devices. Also included in the driver 80 is a code 

name property as "Device Name** 50. It is this name 50 section 90b containing the instructions that are used to 

property mat form a primary basis for matching a driver to properly configure the associated device for integration 

a device under embodiments of the present invention. In an within the computer system 120. 

exemplary embodiment of the present invention, a name It is appreciated that in the event mat a device 80 does not 

property 50 consists of a niiU4erminated string of characters. 20 contain a device name 80c, the operating system 30 or 

Device nodes may also contain a property mat indicates firmware 20 will generate a pscudo name for the device that 

compatible devices 60a to device name 50. FIG. 4 illustrates consists of (1) a vender indicator known by the driver and 

this property as 'Compatible Property*' 60 which provides a (2) the driver type indicating the use of the device used by 

listing 60a of compatible names (eg., namel, name2, and the driver (eg., video card, disk drive, etc.). During inirial- 

name3) of devices that are compatible with the "device 25 ization of the computer system 120, devices not having 

name" 50. These names 60a represent devices that are device names generally communicate this pseudo name to 

compatible with the device indicated by the device name 50. the IEEE P. 1275 procedure so the device tree 10 database 

These compatible names 60a are also used by the present will create a device node having the pseudo name. As win 

invention to match drivers with devices should no driver be described further below, the present invention provides 

match to a device name 50 for a particular device node 10f. 30 randMatr Hbt matting prv^trrg to a<n?unt for the con 

Device nodes 10/ can also contain other properties, for dition wherein more than one coupled device, mmmnnin.^ 

instance 1 *Other Property" 70 includes information regarding the same pseudo name to the device tree 10 database and 

interrupts (IRQ) 70a associated with the device indicated by more than one driver in the system also contains (his name, 

the "device name" 50 as stored in the node 10/. Discussions to follow describe a format and inn?lemen- 

In the discussion to follow, device driver 80 or "native 35 tation of a device drivers 80 as shown in FIG. 5a within the 

device drivers" and families with respect to a particular, environment of a particular software system. It is to be 

exemplary, implementation of one embodiment of the appreciated that the present invention driver 80 can be 

present invention within an exemplary environment It is implemented in a number of different environments and the 

appreciated that the present invention may operate on a implementation to follow is exemplary only and should not 

variety of environments within a variety of different hard- 40 be construed as limiting of the scope of the present inven- 

ware and software platforms and to this extent, the disclosed tion. 

particular embodiment should not be construed as limiting Native device drivers 80 (operable for example on the 

the scope present invention to any particular environment or PowerPC platform) are Code fragment Manager 40 (CFM) 

platform, fragments with the following general features: (1) CFM 

m. NATIVE DEVICE DRIVERS 45 container format; (2) CFM programming interfaces exported 

Under the present invention, native device drivers 88 (or from the driver to Mac OS; and (3) CFM programming 

just "drivers") are stored in several locations within the interfaces imported by the driver from an nrvr»rin g gy*^rn 

computer system 120. A driver 80 (FKj. 5a) can be located such as the Mac OS (Macintosh Operating System). Generic 

in RAM 102, ROM 103 (e*g. t within expansion ROM drivers are CFM fragments mat work with the Device 

located on the device itself), in a file system (eg., on a disk 50 Manager 90 (FIG. 6) and the Driver Loader Library 45. The 

drive 104), or may be directly located within a device node container format for native PowerPC device drivers 80 is the 

lOo-lO* in the device tree 10 database. In the latter case container format supported by the Code Fragment Manager 

device matching is not typically required for a device node 40 (PIG. 7). The CFM format provides all mr^anicmc 

having the driver associated therewith unless a more com- necessary for drivers, is integrated with Mac OS, and is 

parible driver is located elsewhere. For the majority of cases 55 documented in a publication entitled Inside Macintosh: 

the device node does not have the driver associated with it PowerPC System Software. 

in the device tree 10. The present invention automatically Native drivers, both generic and family, export a data 
matches up a device of the device tree 10 with its appropriate symbol that characterizes the driver's functionality and 
driver. The drivers located in the device tree 10 are some- origin. A family is a collection of devices that provide the 
times called default drivers and are said to exist within 60 same kind of functionality. A family can also be "generic" 
device driver property for the node. Drivers located in the (e.g., Device Manager). This symbol, called TheDriverDe- 
file system 104 are referred to as drivers in a "device driver scription 80a, is exported through the CFM's symbol 
folder" and can override the defanlt driver under the present mechanism. Driver Description information helps match 
invention by use of candidate list matching and candidate drivers with devices. It also permits the Device Manager 95 
list priority sorting as described to follow. 65 to pick the best driver among multiple candidates. For 
Pertinent contents of an exemplary driver 80 are shown in example, it lets a newer driver on disk override a ROM- 
FIG. 5a. A driver 80 within the present invention contain two based driver. Native generic drivers 80 export a single code 
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entry point, called DoDriverlO, that handles all Device 
Manager 95 operations. It is a selector-based entry point 
with command codes that specify the I/O action to be 
performed. The device driver can determine the nature of the 
I/O request from the command code (Initialize, Finalize, 
Open, Close, Read, Write, Control, Status, KiiHO, Replace, 
or Superseded) and command kind (Synchronous, 
Asynchronous, or Immediate). The CFM 40 requires that 
fragment imports be identified in some manner. With generic 
drivers, this is done by linking the device driver fragment 
code to the Driver Services Library. The linking lets the 
fragment's symbols be bound at execution time. The Driver 
Services Library should be used instead of a Toolbox-based 
library when linking a device driver. 

Native device drivers 80 can use the CFM's import library 
mechanism to share code or data. With this technique, the 
CFM 40 creates an import library fragment when the first 
driver is loaded. When another driver is loaded, it establishes 
a connection to the existing library, letting the two drivers 
share code or data. 

Hie Device Manager 95 is part of a system software 30 
that provides communication between applications and 
devices. The Device Manager 95 calls generic device drivers 
and it does not manipulate devices directly. Generic drivers 
accept calls from the Device Manager 95 and either cause 
device actions or respond by sending back data generated by 
devices. For further general information about drivers and 
the Device Manager 95, see Inside Macintosh: Devices, by 
Apple Computer, Inc. The Device Manager 95 has tradi- 
tionally been the gateway for device drivers to use the 
Macintosh Toolbox, for example. 

The following discussion describes, in one embodiment, 
the workings of a native driver 80 of the present invention 
under the Device Manager in the Macintosh environment 
("generic family"). In one embodiment, a native driver 80 
receives its parameters through (he single DoDriverlO entry 
point, subject to the calling conventions specified by the 
PowerPC runtime architecture, in one embodiment If a 
DoDriverlO procedure is written in C (for example), the 
correct behavior is guaranteed. A native driver does not have 
access to its Driver Control Entry (DCE) in the Unit Table. 
Thm^iflt^TnrngnmandTTinH is passed in the ioKind param- 
eter to specify that a request must be executed Immediately. 
If so, the driver must process the request completely and the 
result of the process must be reflected in the return value 
from the driver. Initialize, Finalize, Open, Close, KflHO, 
Replace, and Superseded calls are always immediate. If the 
ioKind parameter is either SyncfaronousIOComrriandKind or 
AsynchronousIOCommandKmd, the return value from the 
driver is ignored. The driver calls IOComman dlsComplete 
at some future time. The Tnft1atir.e and Finalize commands 
are sent to the driver as its first and last commands. Tm'tialiTc 
gives the driver information it needs to start up. Finalize 
informs the driver that the system needs to unload it Drivers 
receive all Open and Close calls, which connect the driver 
independently of initialization and finalization. Native driv- 
ers accept and respond to all command codes. The Read__ 
Enable, wrile_J2nable, Control_J2aable, and Status_£nable 
bits in the DCE are ignored. Native drivers must keep track 
of I/O permissions for each instance of multiple open actions 
and return error codes if the permissions are violated. 

The Device Manager 95 processes zero-length reads and 
writes on behalf of the driver. The Code Fragment Manager 
40 sends CFM initialization and termination calls to a driver 
when the driver is loaded and unloaded The CFM initial- 
ization procedure, if present, will run prior to the driver 
being initialized by the Device Manager. It is possible that 
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the driver will be loaded and its CFM initialization proce- 
dure run even though it is never opened and, therefore, never 
closed. It is important that any processing done by a CFM 
initialization procedure be undone by the CFM termination 

5 procedure. The Device Manager 90 may load a number of 
drivers looking for the best candidate for a particular device. 
Only the best driver is opened and remains loaded All other 
CFM connections are closed, causing the CFM termination 
procedure to run. Native drivers 80 do not jump to the 

io IODone procedure. To finish processing an I/O request, a 
generic native driver calls IOCommandlsComplete to notify 
the Device Manager 90 that a given request has been 
completed. 

To determine the kind of request or kind of command, the 

15 Device Manager 95 parameter block has procedure param- 
eters called theCode and theKind. A native driver is reentrant 
to the extent that during any call from the driver to IOCom- 
mandlsComplete the driver may be reentered with another 
request A native device driver does not have any sort of 

20 header. H will however, export a data symbol called The- 
DriverDescription. A driver uses this data structure to give 
header like information to the Device Manager. The Device 
Manager 90 uses the information in TheDriverDescription to 
set the dCtlFtags field in the driver's DCE. A native device 

25 driver cannot make use of the dCtlEMask and dCtlMenu 
fields of its driver control block. Native drivers 80 are not 
used for creating desk accessories. 

The following discussion illustrates exemplary driver 
structures that can be utilized within the present invention. 

30 Hie Native Driver package is a CFM code fragment It can 
reside in RAM or in a device tree 10 as a property. In one 
exemplary implementation it may reside in the Macintosh 
ROM 103, in a PCI expansion ROM 103, or in the data fork 
of a file 104. File-based native driver code fragments contain 

35 no resource fork and have a file type of *ndrv\ The Native 
Driver package may house various types of drivers. The 
driver is expected to support services defined for the par- 
ticular device family. One predefined driver type is a generic 
type and is called *ndrv' (not to be confused with the Native 

40 Driver file type 'ndrv'). The Native Driver package requires 
that at least one symbol be defined and exported by the 
CFM's export mechanism. This symbol must be named 
TheDriverDescription 80a and it is a data structure that 
describes the driver's type, functionality, and characteristics. 

45 Depending on the type of driver, additional symbols must 
be exported. The generic 'ndrv* driver type requires that the 
CFM package export a single code entry point, DoDriverlO, 
which passes all driver I/O requests. DoDriverlO must 
respond to the Open, Close, Read, Write, Control, Status, 

50 KilllO, Initialize, Finalize, Replace, and Superseded com- 
mands. Native drivers must also keep track of VO permis- 
sions for each instance of multiple open actions and return 
error codes if permissions are violated. Other driver types 
that support device families must export the symbols and 

55 entry points defined by the device family or device expert 

Driver Description Structure 

A device driver presents the operating system 30 with a 
self-describing data structure called a driver description 

60 ("DriverDescription'*) 8Q& As shown below with respect to 
a particular embodiment, the driver description 
(*T>riverDescription*°) 80a is used by matching mechanism 
of the DLL 45 of the present invention to (1) match devices 
to drivers; (2) identify devices by category of functionality; 

65 (3) provide driver name information; (4) provide driver 
version information; (5) provide driver initialization infor- 
mation; and (6) allow replacement of currently installed 
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driver. By providing a common structure to describe drivers Driver Runtime Structure 

81, the operating system 30 is able to regularize the mecha- 
nisms used to locate, load, initialize, and replace them. The 
operation system 30 treats any code fragment that exports a 
DriverDescription structure as a driver within the present 
invention. The structure DriverDescription 80a is used to struct DriwOSRuntin* { 
match drivers with devices, set up and maintain a driver's RunthneOpoons driverfajntime; 

runtime environment and declare a driver's supported ser- s* 31 dnverName; 

vices. An exemplary structure is shown below wherein the UInt32 drived>c»cRcacnwdi8j; 

"driver name** 80c (FIG. 5) is located within the driverType 10 opAmBits RintimeOptk^ 

information: typedef stnict DriverOSIumriine DrWerOS Runtime; 

typedef struct friverOSRuxttmie •DriveKJSRmtiiaePtr, 

1 { /*Drir«OSRuEtime fait constants*/ 



struct DriwrDMcription { kdrivcrffl .oafWfUpooDiscovery = l/*auto-toad driver when 



OSType driverDescSignature; 



discovered*/ 



DriverDeecVersion diTverDeacVersiaii; iAwaisOpMMdtJpoiiLo«d = % /Huto-open driver when 

DriverType driverType; . fr is loaded*/ 

Drrvtrf)SRuntime drheOSRuntimemfo; xdrrveflB UnnVaBi | w rtGoil^ = 4, f*VO expat handle* 

DriverOSServioe drivwScrvioes loidt jad open s*/ 

y, lultiv crTsC oD Ci BTeDt = 8, /*6Upports concurrent 

typedef struct DriverDescription DrivetDeacriptjoo; request*/ 

typedef struct DriverDescripuoo •DrrverDc.acriptkatftr; 20 kdnverQueiiesIOPB = 0 x 10 /•Device Mugger 90 does not 

t { queue IOPB*/ 



kThcDcacri^kyiSigiiafiire = 'mtef /*first long of ^ 



DrivcrDeecripbon*/ 



Field 



j» ^^-jjwrPmtf IIHT OptHODS fflfffl tD detBUDlDe runtime 

typedef Umt32 DriverDeeeVersion; behavior of the driver. Tbe bits m this 

conm { 25 field have these meanings: 

klhmamriverDeacriptor = 0/*Vcrston 1 of DriverDc isuipUuu */ TtifMrantn g 
}- 0 system bads driver when driver is 

FkM descriptions: discovered 

n>ivf w f>twKtS| jn tttuPP t system opens driver when driver is 

Signariae of this DfiveiDescjjpuun structure; currency loaded 

Sm^j 1 2 device funuy w^i* twiffaft driver 

drrveiDesc^feamon 30 loads and opens 

Version of this Driver Description structure, used to 3 dn\er is capab le of handling coo- 

dittmgai&h diffiejent venbu of r>iverDe*criptian that current requests 

have tfae same driverDescSignature. 4 106 Device Manager 90 does not 

driverType queue the IQHB fto the DCE leanest 

Sttmctiwn timt ormtainfl Aiwr miiw < nd vffmnn befose calling the driver. 

drrvefOSKunteenito 33 dii v oi N amp Driver name uaed by Mac OS if driver 



type is ndrv. Mac OS copies this name 

which detenmnes how a driver « handled when Mac OS to to name 6r^ cf the DCR Tliis neU 

finds it This structure also provides the driver's name lo ^ is unused for other driver types, 

Mac OS and specifies the driver's ability to support ciiveiDefleReaerved Reserved for future use. 



driverScrvicee 40 
Structure used to declare the driver's supported 



Driver Services Structure 



The DriverOSService structure describes tne services 
supported by the driver that are available to applications and 

Driver lype Structure 45 other software. Each device family has a particular set of 

required and supported services. A driver may support more 
The DriverType structure contains the driver name 8tc than one set of services. In such cases, nServices should be 
and version information about a driver, which is used by the set to indicate the number of different sets of services that 
present invention to match the driver to a specific device. A the driver supports, see below: 

driver type structure is shown below: ^ 

«— — ^— — — — — — struct DriverOSService { 

afruct DriverType { SerriceCount nServices; 

Str31 mmrifrifhSlr; DriverServieemto servicefl] 

NurnVenriao version; }; 

} 53 typedef UTm32 SerriceCount; 

typedef Ubt32 DeviceTypeMember; typedef struct DriverOSServtos DriverOSService; 

typedef struct DriverType DriverType; typedef struct DriverOSService *DrrveiOSServicePtr; 

typedef struct DriverType *DrivaTypcPtr, Field descriptions 

Held descriptions: nServicee The number of services s uupmtal by this driver. This field is 

ngmefnfoStr Name used to identify the driver and distinguish used to determine the size of the service amy mat feOowa. 

between various versions of the driver when an ^ service An array of DriverServixJaib structures that specifies the 
expert is searching for drivers. Ttus string of type supported pwymrntwi^ imrrftff sets. 

Str31 is used lo match the PCI p«™ property in the -■ - - . . , .,, 

Name Registry. 

"Nfa i a i on re so urc e used to obtain the n ew e st driver 

when several kienticalry-oBxned driven (that is. Driver Services Mccmation Structure 

drivers with the same value of namernfaStr) are 

avaiiabie on <£sk- 65 The DriverServicelnfo structure describes the category, 
— ^ — - — — - — — type, and version of a driver's prog ramming interface ser- 
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•continued 



struct DnverServicelnfb { 

osrype 

OST,vpe 
NumVfcrsion 

}; 



aervkeCattgory; 
serviceType; 
servic* Version; 



typedef 
typedef 



struct DrrverServkasInrb DriverServicemfa; 
struct DriverServicelnfo *DriverSerYiceInfoPtr; 



/•used in 
serviceCategory*/ 
/•display*/ 
/•open transport*/ 
/•block storage*/ 
/•SCSI SIM*/ 
/•generic*/ 



union IQComnttTirtCootenta { 
ParmBlkPtr 
DriverlnillnfaPtr 
DriverFinallnfcPtT 
DriverReplacelnf oPtr 
DnverSupenedodEaibiHr 

}; 

typedef union ICX^ommendCanteiitB IOCnfTrmanrtCcnfrrts; 
typedef UInt32 lOConmundCode; 



/•Contents are couunand specific*/ 
!*\ 

in rt ifliTfkficv* 

repLacelnf o; 



kServioeCategoTy Display = 'disp', 
kServioeCategOfYOpentransport = 'otan', 
kSemoeCategoryblcckstorage ~ 'blot, 
kServioeC ategory SC SIStm = 'scsi', 
kSernceCategoryxKkvdrm = *ndrv' 

}; t 

Field descriptions: 

serviceCategcry Specifies driver support services far given device family. 
Some examples of device families am: 
Name Supports services defined for 
'biat block driven family 

'disp' video display family 

'ndrv' gneric native driver 



BerviceType 
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{ 

kOperjConnnand, 

kC loscConiinasid, 

kReadCoctmand| 

kWntcConunand, 

bOotitpp ICocm Bmd| 

kStarnsComrnand, 

UUlHOCommand, 

HnitializeCoinm&nd, 

U^ializeCcmmand, 

kReplaceCcmmand, 



/••ndrv* driver services*/ 
/•open command*/ 
/•close command*/ 
/•read command*/ 



/•control 



}; 



y*kifl I/O command*/ 
/•initialize command*/ 
/*finslixe command*/ 
/•replace driver command*/ 
/•driver superseded command*/ 



'otan' Open Transport 

'scsi 1 SCSI interface module 

Subcategory (meaningful only in a given service 
category). 

servk»\fcrsion ^Version resource Overs') used to specify the version 

of a set of services. It lets interfaces be modified over 



DoDriverlO Entry Point 

Generic *ndrv* drivers must provide a single code entry 
point DoDriverlO, which responds to Open, Close, Read, 
Write, Control, Status, KflHO, Initialize, Finalize, Replace, 
and Superseded commands. 



20 typedef Umt32 K)CcmmmdKind; 
enum{ 



OSBir DoDriverlO (AdorcssSpaccID) 
rOCcmrnandlT) 



ID, 




lOCopirfunirlKmd 
typedef KernellD AddreesSpacelD; 

The address space oom^sxnma me buffer to be pre- 
pared. Mac OS 7.5 provides only one address space, 
so this field must be specified as 
kCurrentAddrcesSDacelD. 
CornrrvanriTD 

loitiaHiift the driver, PrrMliTiationhfo when removing 
the driver, Driver Replttcelnfo when replacing, 
DirverSupersededTnfu when superseding, and 
ParmBIkPtr for «D other VO actions. 
Selector used to determine I/O actions. 
Options used to delnniime how VO actions are per* 
fanned. The bits in mis field have these meanings: 

Bit "Meaning 

0 synchronous VO 

1 asynchronous VO 



}; 

23 struct Driverlnirlnfb { 
Driver RefNum 
RegEntrylD 

}; _ 

struct DrivcrFinaTFnfo { 
Driver RefNum 
30 RegEntrylD 

}; 

typedef 



tmmm. m .1. f 

rypcoei 

,1-f 

35 typedef 

typedef 



40 



refNum; 
deviceficdry; 



refNum; 
deviccfintry; 

T>jyHili-HiTnffrv Drrvc.ritrpracfiTnfo, 

•Driver ReptaonlnfbPtr; 

DrivcrPrnannfo DriverPinaTliifoT 

•DrrverPinani ifuPu , 

DrrvcrFinatlnfo DrrverSupenededhJb, 

•DrncrSuperwinVrifhfpPtr; 



refNum 



LctI%»EDmonmfD{ 
refNum 
RegEntrylD 

}; 



devicefiotry; 



refNum; 
deviceEntry; 



ID 



code 



45 



Getting Command Information 

50 Any rmniiuHvl in progress that the Device Manager 90 
has sent to a native driver can be examined using GetlO- 
Commandlnfo. 



DoDriverlO Parameter Data Structures 

The data types and structures that the DoDriverlO entry 
point uses have the following declarations: 



55 



60 



OeflOCommandLnfo 

QSEc OedOO^Trmtndrhfb (KX>jmmanrfID thelD, 

jjjtjommaxiuuoae -iiot ■ouhlmuk.i, 

lhfH > frnimonrf TJ> 

rheConflents Pointer to the Krf*B or fc rrnaKrW F in a hzc CmikuJ* 
theComrnand Command code 

rheKind Command kind (synchronous, aavnehrcnous, or 

) 



typedef Umt32 
klnvalidlD = 0 



IQCnmrrwnrTTD; 



65 GeUCKZommandlnfo returns information about an active 
native driver I/O command. It will not work after a driver 
has completed a request 
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rypedef 


struct 






typedef 


struct 




♦IlpriaitratinwTiifi^Pir; 


typedtf 


struct 


Final tzsrinnfnfh 


PhTflll/ntirinTnfifv 


typedef 


struct 







RegEntrylD 



"fc^yR^fatw^iriWtMiiitAfff ^ 

(refNum myReOfam, rcgBrtrylDPtr my Device) 



//Remember our reiNum rod Registry Entry Spec 
BAyReftceooeNuniber = myRefNuxn; 
MyDeYkxID = •my Device; 
retuTu noEcr; 

DgFjpgJiwiCfiiiiiiMiud 

(refNim myRcfNuoi, RsgBrtrylDPtr my Device) 



(myRzfNum, myDevice) 




The driver's initialization procedure first check the 
device's AAPL, address property to see that needed 
resources have been allocated. The initialization code also 
allocates any private storage the driver requires and place a 
pointer to it in the static data area that the Code Fragment 
Manager 40 provides for each instance of the driver. After 
allocating memory, die initialization procedure performs any 
other preparation required by the driver. If the handler fails 
to allocate memory for private storage it returns an appro- 
priate error code to notify the Device Manager 95 mat the 
driver did not iwftf«H»> itself. 

In an exemplary embodiment, if the Open Hrnware 
FCode in the device's expansion ROM 103 does not furnish 
either a driver, AAPL, MAacOS, PowerPC property or a 
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Responding to Device Manager 95 Requests 

Native drivers 80 respond to Device Manager 95 requests 
by handling a single call, doDriverlO. Native drivers 80 
must also keep track of I/O permissions for each instance of 
multiple open actions and return error codes if permissions 
are violated The DoDriverlO call interface is described in 
the above discussion. The following sections discuss some 
of the internal procedures a driver 80 uses to service 
DoDriverlO requests. 

Initialization *nd Finalization Routines 

The Device Manager 95 sends Initialize and Finalize 
commands to a native driver as its first and last commands. 
The Initialize command gives the driver startup information 
and the Finalize command informs the driver that the system 
would like to unload it Open and Close actions are separate 
from initialization and finalization rather fra n using Open 
and Close calls as the initialization and finalization mecha- 
nism. A typical framework for a generic driver handler for 
Device Manager 95 finalization and CFM initialization and 
termination commands is shown below: 



10 



15 



20 



unique name property, or if the driver's PCI vendor-id and 
device-id properties are generic, then the initialization pro- 
cedure checks that the device is the correct one for the driver. 
If the driver has been incorrectly matched, the initialization 
procedure must return an error code so the Device Manager 
95 can attempt to make a match. The driver's finalization 
procedure must reverse the effects of the initialization pro- 
cedure by releasing any memory allocated by the driver, 
removing interrupt handlers, and canceling outstanding tim- 
ers. If the finalization procedure cannot complete the final- 
ization request it can return an error result code. In any 
event, however, the driver will be removed. 

Qpen and Close Routines 

A native device driver 80 utilizes both an open procedure 
and a close procedure. The current system software does not 
require that these procedures perform any specific tasks, 
however, the driver should keep track of open calls to match 
them with close calls. Open and close procedures are imme- 
diate. Typical code for keeping track of open and close 
commands is shown below: 



long inyOpcoCount; 
25 OSBtt DoOpeaComaxiDd (PannBIkPrr mePb) 



} 



nxyOpooCouot++; 
retmi dqExt; 



OSErr DoCkneCamrmnd (FumBIkPtr thefto) 

30 I 

myOpenC&iDt — ; 
retmnoEiT; 

} 



35 



Read and Write Routines 



Driver read and write procedures implement VO requests. 
These procedures can execute synchronously or asynchro- 
nously. A synchronous read or write procedure must com- 

40 plete an entire VO request before returning to the Device 
Manager 95, an asynchronous read or write procedure can 
begin an VO transaction and then return to the Device 
Manager 95 before the request is complete. In this case, the 
I/O request continues to be executed, typically when more 

45 data is* available, by other procedures such as interrupt 
handlers or completion procedures. Below is an example 
listing: 



50 



•tort 

long 
O 
{ 



myLuffiir; 
myLMtCooot; 



(lOpbpb) 



55 



60 



nimbytes = pb -> lORegcouot; 



myLtflffiir = myEcr; 
l(nryEcr); 



/* do the read into pb — > 
/• tforeingtobels */ 



Control and Status Routines 

Control and status procedures are normally used to send 
65 and receive driver-specific information. Control and status 
procedures can execute synchronously or asynchronously. 
Below shows a sample control procedure. 
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state. The definition of this state is device-specific, but it can 

—————— — involve such tasks as disabling device interrupts. (3) 

DcControlConimaDd. Remove any installed interrupt handlers. (4) Store the driver 

MyDrivoGlobalsPtr dStore; and the device state in the Name Registry as one or more 

5 properties attached to the device entry. (5) Return noErr to 
OSEir DoControlComiDand (PammBikPtr pb) indicate that the driver is ready to be replaced. (6) The 

* SW te h ( pb _ >csCode) kRerdaceCommand selector tells the incoming driver to 

{ begin assume control of the device. The command contents 

case kCfeaxAil: are the same as a klnitializeComman d. 

dS^T^£Tc>r * 10 ^ ^coriiing driver should take the following actions: 

rctum(ncEir); ~ ' ( 1) Retrieve the state stored in the Name Registry and delete 

default /* always return oontroiExT for unknown csCode */ the properties stored by the Superseded command. (2) Install 

retum<contoiEir); interrupt handlers. (3) Place the device in an active state. (4) 

1 ' Return noErr to indicate that the driver is ready to be used. 

I 15 IV. FAMILY MATCHING 

In one embodiment, families can be stored in several 
The status procedure should work in a similar manner. The locations within the computer system 120. A family can be 
Device Manager 95 uses the csCode field to specify the type located in RAM 102 or in a file system (eg. on a disk drive 
of status information requested. The status procedure should 104). In addition to matching a device to appropriate drivers, 
respond to whatever requests are appropriate for the driver 20 the present invention automatically matches a device of the 
and return the error code statusErr for any unsupported device tree 10 with a corresponding family. A family con- 
csCode value. The Device Manager 95 interprets a status sists of code which, when executed, provides a universal 
request with a csCode value of 1 as a special case. When the interface for software, such as an application program, to 
Device Manager 95 receives such a status request, it returns interface with the selected device driver of that family, 
a handle to the driver's device control entry. The driver's 25 Families include storage devices, sounds, display devices, 
status procedure never receives this request etc. 

KiUIO Routine Pertinent contents of an exemplary family 90 are shown 

in FIG. 56. In the present embodiment, a family consists of 
Native driver KilllO procedures take the following form: a data section 90a and a code section 90b. The data section 

30 90a contains a family description data structure which 
__ ___ includes version information 90c regarding the version of 

^"SS^^L^^ the family code Hfr ^family service calory information 

ream from queue and he* request */ (lc, category name) 90* indicating the type of device for 

return ocEtn which the family is to be used (e.g., disk, video card, etc) 

} /* Ebe, if no request located */ 35 Discussions to follow describe a format and implemen- 

return aborffiir, tatioo of a family 90 as shown in FIG. Sb within the 

foPb Prima to a. Device Mmager parameter bbek environment of a particular software system. It is to be 

i appreciated that the present invention family 90 can be 

wv— • ii ti* implemented in a number of different environments and the 

When the Device Manager 95 receives a KiUIO request, it 40 irr^lementation to follow is exemplary only and should not 
removes tte specified parameter block from the driver I/O be construed as Hrniting of the sc^ of the present inven- 
queue. If the driver responds to any requests fan 

asynchronously, the part of the driver that completes asyn- Families 90 (operable, for example on the PowerPC 
chronous requests (for example, an interrupt handler) might pfctf onn) are preferably Code Fragment Manager 40 (CRM) 
parameter block to me pending request to be at « ^ Xd» f<Li^ (1) CFM* 

ttte head of fce queae. The Device Manager 95 notifies the container format; (2) CFM programming interfaces exported 
driver of KilllO requests so it can take the appropriate from the family of Mac OS?iTS) CFM rm>gramming 
acboasto stop work on any pending requests The driver interfaces imported by the family from an coeS^starl 

mJ^JSZ^ MaMgCr 95 ^ s«ohasthn^(M«cSoperatinT^n).^ 

ICX^mmandlsComplete. » container format for families 90 is the container format 

Replace and Superseded Routines supported by the Code Fragment Manager 40 (FIG. 7). The 

T . . L . CFM format provides all mechanisms necessary for 

• Under certain conditions, it may be dearable to replace an families, it integrated with Mac OS, and is documented in a 
msta^drrver 80 For example, a display card may use a publication entitled Inside Macintosh: PowerPC System 
temporary driver during system startup and then replace it 55 Software 

with a better venion from disk once the file system is The families are part of a system of software 30 that 
running and initialized. Replacing an installed driver is a provides communication between application programs and 
two-step process. First, the driver to be replaced is requested devices. The family 90 calls device drivers and it does not 
to give up control of the device. Second, the new driver is manipulate devices directly. Drivers accept calls from the 
installed and directed to take over management of the <o family 90 and other cause device actions or respond by 
device. In one embodiment, two native driver commands are sending back data generated by devices 
reservedfor these tasks. The kSimersededOnnmand selector 

tells the outgoing driver to begin the replacement process. Family Description Structure 

The command contents are the same as with kFinalizeCam- A family presents the operating system 30 with a self- 
mand. The outgoing driver should take the following 65 describing data structure called a family description 
actions: (1) If it is a concurrent driver, it should wait for ("Ta^lflyDescription , •) 90a. As shown below with respect to 
current I/O actions to finish. (2) Place the device in a "quiet" a particular embodiment, the family description 
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("familyDescription") 90a is used by matching mechanism 
of the DLL 45 of the present invention to match devices to 
families. By providing a common structure to describe 
families 80, the operating system 30 is able to regularize the 
mechanisms used to locate, load and initialize them. Hie 
operation system 30 treats any code fragment that exports a 
Family Des cription structure as a family within the present 
invention. The structure family description 9Qa is used to 
match families with devices, set up and maintain a family's 
runtime environment and declare a family's supported ser- 



20 



vices. An exemplary structure is shown below wherein the 
family name, or category name 90e (FIG. 5b) is located 
within the familyType information. 
The family type structure contains the family name or 
5 category type 9te, which is used to match the driver to a 
corresponding family. The Family OS Run Time structure 
contains information that controls how the family is used at 
run time. The family description describes a number of 
elements including version and type information for the 
family. 




kfamUylaLowLcvel =1 
typedef UInl32 FamityLcvel; 
/* Family Typing *"fr*«m*™ Used to Mitch Families With 
street FamilyType { 

FamUyLewel namtyLevel; 

OSTypc familyNsme; 

Hon Vmioo ve r s i on; 

OSTypo reserved; 



typedef struct Pamir/Type 
typedef FamilyType * 
{ 



FamilyType; 
FamtiyTypePtr, 



HtonDyKLosdedAlBoot =0x00000001, 
kftmDylsLoadedUpGoDtscowy =0*00000002, 
fcFsniifyltftartodAiBoot = 0>O000C0O4, 



>; 

typedef UInt32 FamifyOSRunTimeOptions; 
struck FvmlyOSituaTime { 

Str31 fanrilyName 

Umt32 famityDo8cReoerve<l[8 ] ; 

}; 

typedef struct FamilyOSItmTime FomilyOSitunTane; 

typedef FamOyOSRmTimD FamilyOSfoiiiTimePtr. 
/* The Fsmfy Descripticm •/ 

kf aniDyDescriptinntSigjiaiMrc = *fdes* 

>; 

typedef UInt32 F%mUyDeoc\^saosx; 
KMnthmflosrdT>*cripto = 1 

}; 

typedef Ubt32 DependfbncyCount; 

StrUCt M«tnK?^ g ATwfTV|i»wA.riff yWir> 



/•High Level Family*/ 
/•Low Level Family*/ 



plug-ins an Devices/* 

/* Kind of Family*/ 
Family Name*/ 

/* Family Vama Number*/ 
Used by Motto BcMrd£xperrV 



/•Family is loaded at the boot tuns*/ 
f* auto-load Family when diaujv cie d* / 
f* Family is at boot*/ 



/* Options for OS Runtime*/ 
/* Family's name to the OS*/ 
/* Reserved area*/ 



} 



{ 

Str31 
OSType 



/* the device name to match*/ 
f* Upendency List f 



[XI; 



typedef struct M a t c lrin gAiidD c p cp o ra icylnfo 
typedef M**ff^t^g-AtvtrwipwfMfai m ;yti ifr> * 
struct FanalyMsJtohnigAiallVipaidBncy { 
DependencyCount 

typedef struct F^imJ yMatrhngAii^iKi s lri i f' . yl nfo 
lyrrW ^^hmf A ~ ffVi r*" y * 
atnn.it FaflailyDoflcnppJOD { 

OSType fsmflyDrecSignstistt; 

FaaalyDcsLVtiiaioji nmnTyDiJS fc Mji sfc ip ; 

FamilyType CamflyTypc; 

FaimlyOSRunTinie famTyOSRuniimc; . , 

"Pami yyix^WmjAni DependciHy fr™ «Tymtr>m>y AT^TVp^vWiry /• Family Depeudoocy Info*/ 



MsBrJhmgAncfl^pepdflDujLifo; 
MaintiiingAndIV>pcta^BncyIiifcPo^ 

/* Number of ekanonts in the array*/ 



Matrha^gAiMJVipffalency; 
Mifclm^gAiaiDrpenrtencyPir; 

/» Signstnrr fifed cf this structure*/ 
/* \*«iou of mis data of femily*/ 
/•Type of Driver*/ 



typedef struct FaniOyDescriptKio 
typedef FamilyDeacnptiaQ * 



FamDyDoscripdoiu 
FamdyDescrmtsonPtri 
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V. DRIVER LOADER LIBRARY 

With reference to FIG. 6, the Driver Loader Library 45 
(DLL) of the present invention is further discussed. FIG. 6 
illustrates the relationships of the DLL 45, ROM 103, the 
Device Manager 95, and a driver 90 of the present invention. 
The Device Manager 95 communicates with a native driver 
80 (for example, open, close, read, write, control, status, 
KilUO, Replace, and Superceded commands). The Device 
Manager 95 also communicates with the DLL 45. The DLL 
45 gives commands to the native driver 80 such as Initialise 
and finalize commands. In one implementation, the DLL 45 
is a CFM shared-library extension of the Device Manager 95 
and provides services to locate, install, and remove drivers. 
The DLL 45 utilizes procedures of the CFM 40 for opera- 
tion. The DLL 45 provides services that control aspects of 
driver to device matching under the present invention and 
also driver loading and installation. Under the present 
invention, driver and family loading is an automatic pro- 
cesses that frees drivers from having to perform device 
matching themselves. 

FIG. 7 illustrates functions of the DLL 45 of the present 
invention. At logic block 200, the present invention per- 
forms driver matching and family loading which includes 
detenxunation of a particular driver and family for a par- 
ticular device of the device tree 10 database. In order to 
perform this, logic block 200 interfaces with the name 
registry (also called device tree 10 database) and also with 
RAM unit 102 and ROM unit 103. Drivers and families may 
be located in these memory units. The file storage 104 
(where drivers may be located in the device driver and 
families folder) is also coupled to communicate with the 
logic block 200. The CFM 40 is also coupled with block 
200. The DLL 45 performs driver matching and family 
loading in block 200 as well as device installation 210 once 
an a ppr op riate driver is selected for a device. At block 220, 
information retrieval is performed which allows a user to 
retrieve particular information about a recognized driver. 
Also, the DLL 45 of the present invention performs driver 
removal at block 240. These functions will be discussed in 
further detail to follow. 

FIG. 8 illustrates a flow diagram of processing performed 
by the DLL 45 of the present invention for automatically 
matching device drivers 80 to a particular identified or 
selected device of the devices reported in the device tree 10 
database usin g ca nd frtpte lists and sorting. This process is 
repeated for each device of the device tree 10 starting from 
the top and continuing downward through the tree 10. 
Processing 200 is invoked upon a request to locate a driver 
and associated family for a given or "selected" device. 
FTocessing logic 200 starts at block 305 wherein a candidate 
list is constructed and is associated with the selected device. 
This list contains a grouping of those drivers having a driver 
name that matches with the given device's device name or 
compatible device name. These drivers represent a set of 
drivers mat perhaps will properly configure the given 
device, FIG. 9a illustrates the steps performed by logic 
block 505 in more detail. 

With reference to FIG. 8, after a candidate list is 
constructed, the present invention flows to logic block 310 
wherein the candidate list is sorted by priority ranking as to 
which members of the candidate list are more than likely to 
match with die selected device and those drivers that are less 
likely to match with the selected device. The steps per- 
formed by logic block 310 are further described with refer- 
ence to FIG. 10. With reference to FIG. 8, after a candidate 
Hst is sorted by priority ranking, the present invention flows 
to logic block 600 wherein DLL detennines the list of 
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families required and installs them. Exemplary steps per- 
formed by logic block is shown in FIG. 9b. With reference 
to FIG. 8, at block 315 the present invention determines 
family requested to the DLL 45 to actually install a driver to 

5 the selected device. If installation request is made, the DLL 
installs the requested drives in block 210. 

At block 330, the present invention instructs the operating 
system 30 to scan the devices of the computer system 120 to 
determi ne if all of the devices that the selected device needs 

10 to operate (the "parent devices") are present within the 
computer system 120. If the parent devices are present, then 
the selected driver can be installed. Since devices of the 
device tree 10 database are processed through the DLL 45 of 
the present invention from top to bottom, the parent devices 

is for a particular selected device should be operational (e.g., 
processed through blocks 200 and 210) before the selected 
device is processed by the present invention. If the required 
parent devices are not operational yet or not present, then 
block 210 is avoided. If the required resources are available, 

20 then at block 210 the present invention performs an instal- 
lation wherein the determined driver is installed with respect 
to the selected device and the device becomes active. It is 
appreciated that the processing of logic blocks 200 and 210 
are typically performed at initialization for each device of 

25 the device tree 10 database, starting with the top node and 
working down the device tree 10 so that parent devices are 
configured first before their child devices are configured. 

With reference to FIG. 9a, a flow diagram is illustrated 
describing the logic steps of the logic 305 of the present 

30 invention DLL 45 in constructing a candidate list of drivers 
for the selected device. Logic 305 starts at block 410 
wherein pertinent information regarding the device nodes of 
the device tree 10 database are accessed for the particular 
device. If the particular device has an associated driver 

35 within its node of the device tree 10 (e.g., a "default driver**)* 
processing continues because this default driver can become 
replaced by an updated driver depending on the priority of 
the drivers in the Candida te list built for the selected device. 
At block 410, the present invention obtains the following 

40 p roper ti es: (1) the device name 50; and (2) the compatible 
names 60a of the selected device (see FIG. 4) located within 
the compatible property 60. After the formation of logic 
block 410 is accessed, the present invention at logic block 
420 then access the available drivers recognized in the 

45 system to construct a first set of drivers. These drivers may 
reside in the device tree 10 database, in the ROM 103, in 
RAM 102 and in the extensions folder (e.g., device driver 
folder) of the disk drive 104. At block 430, the present 
invention selects a first driver for comparison. This driver is 

50 the "given driver." At block 430, the candidate list for the 
selected device is then cleared so the new list can be created. 

At logic block 440, the present invention examines the 
DrrverDescription Ma information for this given driver to 
determine the driver name 80c (FIG. 5) of the given driver 

55 which is stored in the Driver Description, in one 
embodiment, as the "nameinfostr field** of the deviceiype 
structure for the given driver. Importantly, at logic block 
440, the present invention performs a comparison between: 
(1) the device name 50 of the selected device and the driver 

60 name 80c of the given driver; and also between (2) each 
coTnpatiblr name 60a of the selected device against the 
driver name 80c of the given driver. If there is a match 
between (1) or (2) above, then the match characteristics are 
recorded (e.g., was it match by (1) or by (2)) and at logic 

65 block 450, the given driver is added to the candidate list for 
the selected device if a match in 440 happened. It is 
ar^xedated the candidate list can be stored in RAM 102. Hie 
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processing of the present invention then flows to logic block 
460. If there was not a match at block 440, then the present 
invention flows to block 460 without adding the given driver 
to the candidate list 

At block 460, the present invention determines if the 
given driver is the last driver of the drivers discovered in 
block 420 (e.g., those drivers recognized by the computer 
system 120). If so, then the process 305 exits from block 
460. If not, men logic block 460 is exited and processing 
flows to block 470 wherein the present invention selects the 
next driver of the set of drivers discovered in block 420. This 
next driver is then the "given driver" and processing returns 
to block 440 to determine if this next given driver should be 
added to the selected device's candidate list. As with any 
driver, the next driver selected at block 470 can reside in 
RAM 102, in an extension ROM 105 within the device tree 
10, or within a file on the disk 104. At the completion of 
process 305, an unsorted candidate list is then constructed 
for the selected driver and is stored in RAM 102. 

With reference to FIG. 10, the logic steps of logic block 
310 are illustrated. Block 310 performs the candidate list 
sorting for a particular candidate list associated with the 
selected driver. At block 460, the candidate list for Che 
selected device is accessed in RAM 102. This is a candidate 
list generated by logic 305 and is particular to the selected 
driver. At block 470, the present invention sorts the candi- 
date list and places those drivers at the top or head of the 
candidate list mat have a driver name 80c that matched with 
the device name 50 of the selected device. At the same time 
or sequentially, block 480 resolves any prioritization ties by 
using version information stored in the driver description 
between drivers of the candidate Hst Those drivers with a 
more appropriate version (eg., highest version or version 
dosest to the selected driver) are placed higher in the 
candidate list priority. Block 470 then places in lower 
priority those drivers having a driver name 80c that matched 
with the selected driver's compatible names 60a. Again, 
version information (in logic block 480) with respect to 
these drivers is used to perform prioritization the same as 
discussed above. At the completion of block 480, the can- 
didate Hst for the selected device is sorted by priority of most 
likely for validation (e.g., most likely to be compatible with 
the selected device). 

With reference to FIG. 96, the logic steps of logic block 
600 of the present invention are illustrated. Block 600 
performs a procedure to find suitable families for the match- 
ing drivers and installing mem. Once the families are 
installed, the installation of drivers in the sorted candidate 
list is attempted. At logic step 610, the present invention 
accesses the sorted candidate Hst for a particular device. At 
block 620, the present invention accesses or "gets" the first 
driver of this candidate Hst At block 630, the present 
invention reads the category information from the driver 
descriptor 80a. At block 640, the present invention checks if 
the category is already required by the drivers processed 
previously. If the test return "yes", the present invention 
flows to block 660 otherwise it goes to block 650. At block 
650, the present invention adds the category information to 
the Hst of categories required in flows to block 660. At block 
660, the present invention determines if the selected driver 
was the last driver of a selected candidate Hst of the selected 
device. If not, the processing flows to block 670 wherein the 
present invention selects the next driver in sequential order 
from the sorted candidate Hst of the selected device. Pro- 
cessing then flows back to block 630. 

Preferably, when all the drivers in the selected list are 
processed, processing flows to block 680 wherein the 
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present invention finds a matching family either in RAM 
unit or 102 or the file storage 104. During the matching in 
block 640, the DLL compares the category information read 
in block 650 to the category name of the family 90a. If more 

5 than one family for the same category is present, DLL 
selects the family with the higher version number in 90a 
(FIG. 5b). At block 690, the present invention loads and 
installs the families found in block 680. During the instal- 
lation phase, families attempt to install the best driver 

to candidate for the particular device. The steps performed to 
select the best driver are further defined in FIG. 9c. 

With reference to FIG. 9c, the logic steps of logic block 
690 of the present invention are illustrated. Block 690 
performs a procedure of attempted installation of the drivers 

15 of the candidate list for the particular device (e.g., a trial and 
error approach based on the prior information compiled by 
the present invention). At logic step 510, the present inven- 
tion accesses the sorted candidate list for the particular 
device. At block 520, the present invention accesses or 

20 "gets" the first driver of this candidate list At block 530, the 
present invention attempts to install this selected driver with 
the selected device to validate the match. The selected driver 
validates the match by probing the device and performing 
some diagnostic operations between the selected driver and 

25 the device. Any number of different diagnostic operations 
can be used within the scope of the present invention for this 
step. Assuming the selected driver is appropriate, at logic 
block 540, the selected driver confirms the validation by 
returning a **no error'' status flag to the DLL 45. If an error 

30 status was returned, or the "no error" status fails to return, 
men processing flows to logic block 570 wherein the present 
invention determines if the selected driver was the last driver 
of the selected candidate list for the selected device. If not, 
processing flows to block 560 wherein the present invention 

33 selects the next driver in sequential (eg., priority) order 
from the sorted candidate list of the selected device. Pro- 
cessing then flows back to block 530 to determine if the next 
driver will validate the match with the selected device. 
At block 570, if the selected driver happens to be the last 

40 driver of the sorted candidate Hst, then at block 580, the 
present invention returns an error code indicating that no 
cornpatible driver could be found for the selected device. 
Returning to block 540, the present invention flows to logic 
550 if the selected driver did indeed match wim the selected 

43 device. At block 550, the selected driver's category infor- 
matioD is then compared against the category informatioD of 
the selected device which is stored in the device tree 10 as 
property information. Jf no match is performed between the 
categories, then the match is not validated, so processing 

50 returns to logic block 570. If the categories match, then at 

. block 555, the selected driver is said to be determined and 
a proper validation of the match occurs between it and the 
selected device. This Mormarion is then returned from 
block 320. 

33 The operating system 30 can utilize the above logic of the 
present invention at various times, but in one embodimeat it 
is used during the boot phase and at any time a new device 
is added to the device tree 10 (which can also add new 
drivers to the available Hst of drivers used by the present 

60 invention). It is appreciated that as the system boots and new 
devices are configured and **wake up" and are added to the 
device tree 10 (by IEEE P. 1275), it is possible for a device 
to be assigned a driver via the present invention and then 
re-assigned a newer or more appropriate driver later as they 

63 become available during the boot phase. In other words, 
drivers located on the hard disk are not available until the 
hard disk itself becomes configured as a device. In such case, 
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the scope of drivers available at block 420 (FIG. 9a) of the 9. Sort the list created in step 8 using version number field 

present invention is dynamic during the boot phase and will in the driver descriptor 80. Append this list to list 

increase as soon the as hard drive is properly configured. In previously created in step 4. 

this example, a particular device can be initially configured 10. Repeat steps 7, 8 and 9 until there are no mare values 

with a driver from ROM and subsequently can be reconfig- 5 left in the property read in step 6. 

ured with a more appropriate driver from the driver folder of u Create "driver-ptr M property in the name registry 

the hard drive because the new driver will become higher in referring to the list of drivers found in steps 4 and 9. 

the candidate list (oyer the old driver) upon subsequent ^ me category information stored in the driver 

processing of the particular device by the present invention. descriptor of all the drivers present in the list created in 

Therefore, the candidate lists for a particular device are 10 stcps £ ^ g 

^marnic in that they will grow depending on the set of Ust created in step 12 and remove duplicate 

drivers that are available within the computer system 120 AJ " ^ . m urcmcu m »«y p 

and recognized by the present invention. categories. 

More specifically, the processing for matching a driver 14. Scan the file storage 104 for all available families and 

with a particular device can operate at a first time given a is read their family descriptor 90 in RAM 102. 

first set of drivers recognized by the system. A high priority 15. Get the next (First) service category from the list 

driver from a first candidate list can then be determined from created in step 13. 

the present information. Later, at some subsequent time a 16. Find family with highest version number mat have 

new, larger set of device drivers can become available that same service category as value read in step 15. 

will lead the present invention to generate a second, updated 20 17. Load and install the family found in step 16. 

candidate list which will indicate a new, more updated high 18 jjrform famfly about the selected node. 

priority driver. If <*J»"!"^ 19. Repeat steps 15 and 18 until no more values left in the 

remove the original high priority driver from the particular ^ J^^jT ^ 

device and repkejh with the updated high priority driver, m following h ^ mc p^m appo- 
se* below under "Dover R^acement 25 ^ ^ * Nq 08/435,676, filed May 5, 1995) and 
Below is a descrip^nof apaAcular, exemplary, embodi- ^ cmbo< ^ t of the mventions presented herciiL 
mcnt of the system of the present invention service proce- r 
Aires and driver handling, it is appreciated that while a Loading and Unloading 
particular platform is presented below, the functionality of . „ A _ _ . . . 
me rreseiit invention can be readily adapted to a variety of so In one emboaiment, a arrver 80 of the present invention 

different platforms and the below discussion is exemplary ™* * load f fom ^5™ c ?^ tam f £ ne ^^ 

only of a particular imriementation. or resources) as well as from a device's dnver property in 

fotheboc^rcocessTcpe^ * c Name Registry 10. 'following services are^r*ovided 

(FIG. 2) describing the hardware devices present in the ^ this purpose: (1) G^y^rmoryPr^^^ a 

coinr^sy^nTTOs device tree is inserted in the system 33 dnver from a memory range; (2) GetDnverEhskFragment 

nanTraistry 10 defined in FIG. TThe system of the loads a ^ a m * < 3 > FmdMverCanmdatcs and 

prcseminve^on uses the d™^ ScaiiDriverCandidates prepare a list of file-based drivers 

find the devices present in the system, locate me drivers that potentially match a device; (4) FindDriversForDevice 

available to drive present devices and families required to '*? "*f ***** for S !*^<^^ 

control those device drivers. 40 and disk, without making a CFM connection; (5) GctDriv- 

During the booting process, some families may discover «^vice finds the ^besT driverfora device and returns 

additional devices present in the system After discovering * OMcoi^ 

such devices, the families will request service to append the mines whether or not memory is held for a driver, 
device tree in the name registry with newly discovered One circumstance in which HndDnversForDevice or 
devices. When a device is discovered (device tree created by 45 GetDriverForDevice is required is when there is a device 
the open firmware is treated as devices discovered by the aode in the device tree 10 that does not have an associated 
present invention), services of the system are requested On driver. One instance when this might happen is if a PQ card 
receq* of a service request, the system performs the follow- is entered in the device tree 10 after system startup, find- 
ing steps: DrrversI^Device does not create a CFM connection for the 

1. Scan the file storage 104 fcraU available device drivers 50 driver it finds. This service is useful if there is a need to 
and read their driver descriptor 80 in RAM 102. teowse potattal dnvers for a device without loading thenL 

2. Check the name registry f orany ROM 103 drivers for ^^f^* ^ ^er and creates a CFM 
the selected device. Add it to the list created in step 1. connection icr u. 

3. Re^the-W>» of me selected In one ernbodin^nMhe load ofa dnver yieWs 

■anT 55 the following results: ( 1) a CFM ConncctionID; (2) a pointer 

registry. to the Driver Description; (3) a pointer to the DoDriverlO 

4. Create a list of dnvers wmch have the same name m the entry point If the driver has a CFM initialization procedure, 
driver descriptor 80 as name read in step 3. it will be executed. The initialization procedure should 

5. Sort me Ustci drivers created in step 4 using the version return noErr to indicate a successful load. Note that multiple 
number field in the driver descriptor 80. ^ drivers may be loaded in order to determine the best device 

6. Read the "compatible** property of the selected device to driver match. Therefore, a driver's CFM initialization 
from the name registry. This property may contain procedure should not allocate resources that cannot be 
more than one value. released in its termination procedure. 

7. Get the next (First) value of the property read in step 

6 35 GetDriverMemoryFragment 

8. Create a list of drivers which have the same name in the GetDriverMemoryFragment loads a code fragment driver 
driver descriptor 80 as value read in step 7. from an area of memory. 
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OSEir CktDrWerMemoiyFragment 
(Ptr mexnAddi; 

Str63 fragNamt, 

NuDrivdEatryPoiiitPtr »fragmraTtMaTn, 

DnvcdVaciipUonPtr *tbcDnverDesc); 

memAdcfc pointer to the beginning of the fragment in 



length of the fragment in memory 
optional of the fragment 
(primarily used by debugger) 
fragmentOonnlD resulting GFM cooDecbonlD 

resulting pointer to DoDriverlO (may be nil) 
resnltfng pointer to DriveiDescription 



fragName 



fragmentMain 
tncDnvczOesc 



Boolean 

FBeBasedDrivexRecordPtr 

ItemCount 
3 devicelD 

propBasedDrivcr 
propBasedDriverSize 
devkeName 
propBasedDriverType 
gotPropBasedDriver 
10 fikBaaedDrivere 
nFileBasedDrivers 



♦goo?ropBasedDriver t 
nJeBasedDrxvero, 
•nFileBaaedDrivers); 
Name Registry ID of target device 
Address of property-based driver 
Size of property-based oYiver 
Name of device 
Type of property -baaed driver 
True if property-based driver was found 
List of sorted file-based driver records 
Count of fife-based driver records 



15 



Given a painter to the beginning of a driver code fragment 
in memAddr and the length of that fragment in length, 
CretDriverMemory Fragment loads the driver. It returns the 
loaded driver's CFM connectionID value in 
fragmentConnID, a pointer to its DoDriverlO entry point in 
fragrnentMain, and a pointer to its driver description struc- 
ture in theDriverDesc. 
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RESULT CODES 




25 


noExr 

All CFM era 


0 

DCS 


No error 





GetMverDisiPragment 

GetDrrverDi&iAagment loads a code fragment driver 
from a file using the CFM search path. 



OSEtj QetDiiwiiDiskjFraginent 



Given the name entry ID of a device, FiridDrivcrCandi- 
dates constructs a candidate list of file-based drivers that 
match the device name SO or one of the device-compatible 
names 60a. The list is sorted from best match to least 
favorable match. In one enibodiment, drivers 80 that match 
the device name are listed before drivers that match a 
compatible name. Each of these groups are further sorted by 
version numbers, using the HighcrDriverVersion service. 
Property-based drivers are always matched using the device 
name and are returned separately from file-based drivers. An 
I/O expert can determine a property-based driver's randing 
using the HigherDriverVersion service. If a property-based 
driver is not found, all outputs are zeroed. If a nil list output 
buffer is passed, only the count of matched file-based drivers 
is returned. An VO expert can call FmdDriwCandidates 
first with a nil buffer, allocate a buffer large enough for the 
list, and men call HndDrrveiCandidates again with the 
appropriately-sized buffer. If a nil value is passed in 
devicelD, all drivers from the Extensions folder are 
returned. When using this option, pass nil values for all 
parameters except fileBasedDri vers and nHleBasedDrivers. 
35 The list of matched drivers consists of an array of file-based 
driver records: 
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MtiTWwwi>nitfiyPl....lPlr 

DrvnsDescnpdooPtr tiieDriveiDesc); 
fngmentSpec pointer to a file system specification 

fr aginen tfSoiiiID iesultingCFM «yi inert iocJD 
frag men tMain remitting pointer to DoDriverlO 

qViksDbsc resulting pointer to DnYcrDescnpbcai 



struct FilfinsawffVivfFRpflOfd { 

40 FSSpec theSpec; /* file s pecifi ca tion*/ 

DriveiType tneType; /* nsmemfoStr + 

~ rrnyatiblrP pr y ; /* true if mft* using a 



Given a pointer to a CFM file system specification, Get- 
DxrvciDiskFnigment uses the CFM search path to find and 
load a driver code fragment It returns the loaded driver's 
CFM connectionID value in fragmentConnID, a pointer to 
its DoDriverlO entry point in fragmentMain, and a pointer 
to its Driver Description in theDriverDesc. 
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UfatB pad[3); 

}; 

typedef struct RkBasMDrmritecotd 

KkBssedTJriwritoooid, yu fr Bs sedDrbtsftpcoafftr, 



RESULT CODES 

0 
-43 



A file-based driver consists of a file specification, the driv- 
er's type, and whether the driver was matched using the 
50 dwarianttOfaccimiauT)ledevice name. An IA3 expert can 
use the program logic summarized below to cycle through a 
list of file-based candidates. 



AH CFM errors 



No ecsor 
Kfe not found 



55 FmdDmerCaaidatoe ( ); /* get list of 
wink (Csndadates in me list) 



flora devise*/ 



FindDriverCandidates 



(RegBzxtrylDPtr 
Ptr 

RcgPropertyVihjoSize 

StnngPtr 

Drheriype 



devicelD, 

♦pJopBasodDrivet, 

^pTOpBasedPffiyerSge, 



60 



65 



*piopBaspdDnverTypc 1 



OefDnvedPiooiFQe (FSSpec-n>Jlooard, *<fcnwwfVmriw< tM^ip 
if (mitialtuIhisDim(CacBclato <■= NatMyHjodwarefizror) ) 
< 

// Untold mis failed Oliver's a 
// sod Close its CFM CmwmrlsM 

TJnloafn^hsD^rrjRer ( ^frp^w ^f ^inftc ^^^^ 1 ^ ^ 
// Advance to next position in me HsL 
n * * i N r i *Ca ndidatr( ); 



breaks // driver loaded and initialized. 
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-continued 


RESULT CODES 




doBot 


0 No error 




-43 Rk not found 


All CFM errors 




ScariDriverCandidates 



OSBir ScariDriverCandidates 
(RegEntrylDPtr 
FiloBasedDriverRecofdPtr 
IteoaCount 

IttgflCount 
dsvicdD 
fikBaaedDriven 
oFikBaeedDrivers 



devicelD, 
filoBasedDrivers, 
nFUeBasedDrivers, 
mstchiQgDnvwBy 
*nMstcfcmgr>rivcn); 
Name Registry ID of target device 
List of sorted file-based driver records 
Count of file-baaed driver records 
File-based driver records (a subset of 
fikBasedDrivers) 
Count of driver records (<= nHteBssedDriven) 



Given the name entry ID of a device and a list of FOeBased- 
DriverRecord elements, ScanDriverCandidates constructs a 
list of matching file-based drivers that match the device 
name or one of the device-compatible names. The list is 
sorted from best match to least favorable match. Input to this 
service is an array I&BasedDriverRecord elements. Appli- 
cations can use ScanDriverCandidafes to match drivers from 
a static list of candidates without having to incur the 
overhead of disk VO operations. 
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25 
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RESULT CODES 


doEzt 


0 


No error 


fnffiir 


-43 


Hie not fond 


AUCFMena 


ra 





FindMversForDevice 

FindDriversForDevice finds the driver from a file or from 
a device tree property that represents the "best** driver for a 
device— that is, the latest version of the most appropriate 
driver. The procedure for determining a best driver is 
described with reference to FIG. 11 of the present inventiorL 



so 



OSBrr Fmdr*ivtjaR*Dgvioe (RegEntrylDPtr device, 

FSSpec *frigLuefJtSpoc, 
DnvcrDcs cri p ti on *DTcDfTVfflTWwc > 
Pb7 ^^DCTOAddr^ 
Int^g ^length, 
StrmgPtr fragName, 
DnverDcscrrpbOD *■ ■ nTWiwuffcwa^ 

device device ID 

frgflpimfflp—'. pointer to ■ file system specification 
filcDrivuiDosc poinlBf to the Driver Description of driver in > file 
nenkAddr pointer to driver addicm 55 

length ^^jt*^ of driver code 

frsgptamc fitiin" of dnvcr fragment 

mwnfiwwwiw jtfHiiri to the Driver Description of driver in mrayry 



Given a pointer to the RegEntrvID value of a device, 60 
FmdDriversForDevice finds the most suitable driver for that 
device. If the driver is located in a file, it returns a pointer 
to the driver's CRM file system specification in frag- 
mentSpec and a pointer to its Driver Description in 
fileDriverDesc. If the driver is a fragment located in 65 
memory, FmdDriversForDevice returns a pointer to its 
address in mernAddr, its length in length, its name in 



30 



fragName, and a pointer to its Driver Description in mem- 
MverDescJkdDriversForDevice initializes all outputs to 
nil before searching for drivers. 



RESULTCODES 


□otErr 


0 


No error 


fnfErr 


-43 


File not found 


AHCFMexro] 


re 





GetDriverForDevice 

GetDriverForDevice loads the "best** driver for a device 
15 from memory. The procedure for a^termining the best driver 
for a selected device is described in with reference to FIG. 
11. 



OSErr GetDriverForDevice (RegEntrvTDPtr derioe, 

ComectionTP *fxagP>ertCoriiilD ) 

DrrverDesciiplioiiPti *dnverDesc); 
device device ID 

frflgrrwirf^^ m |\TT^ pO^D^Br to S ff **\gl il^^ CPIMMECtFOIl 

nvgincotMun pointer to DoDrivexIO 

driver Desc pointer to die Driver Description of driver 



Given a pointer to the RegEntrvID value of a device, 
GetDriverForDevice loads from memory the most suitable 
driver for that device. It returns the loaded driver's CFM 
connectionlD value in tragmentConnlD, a pointer to its 
DoDriverK) entry point in fragmentMain, and a pointer to its 
Driver Description. 



35 



40 
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RESULT CODES 



0 
-43 



No error 

FBcootfbund 



All CFM 



SetDriverOosureMemory 



OSEir SejDr i v cr Ctoa ujTiM e iiJ ory 
(CXHg&xmectionlD 



frkgnKneCcuiID 
holdDrrvcrMemory 



boUDriverttorjory); 
ID of driver closure (returned from other DLL 
loading service*) 

true to hold the memory of a driver closure; false to 



In one ernbooUmcnt, a driver 80 and all its libraries is 
called a driver closure. When a driver 80 is loaded and 
prepared for initialization by the DLL, memory for its 
closure may be held as the final step in implementing 
GetMverMenwiyRagment and GetDriverDiskRagment 
SetDriverOosureMemory lets one do this by setting the 
holdDriverMemory parameter true. SetDriveiOosare- 
Memory can also be use to free memory held for a driver 
closure by setting the holdDriverMemory parameter false. 
To undo the effects of GetDriverMemory Fragment or 
GetDriverDiskftagnient, an VO expert can call SetDriver- 
MerooryQosuTCMemory (cfrnlD, false) followed by Qo- 
seConnectton (&cfmID). This has the effect of unloading the 
driver. Listing below shows a sample procedure to perform 
this task. 
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void UnloacflbcDrivCT ( CFragComKctiooID frag© ) 

{ 

OSEa- Status; 

THz theOmentZone = GetZooc ( ); 5 

// Make sure the fragment is attached to the system context 

// (System 132 CFM keys context from me current heap zone) 

SetZooe (SystemZone ( )); 

Status = SetDrrverCtoeurtMemcry (tragID, false); 

if (Status t=noErr) 

printf ("CoukkVt unhold pages of Driver Closure! \q 
(Eir=%x]ter,Statw); 
Status = CkneCcsmectkn (&fragID); 
if (Status t=noErr) 

printf ("CoukaVt cbse Driver Connection! 
(Eor=%x>tf\ Status); 
// Reset the zone 
SetZooe ( theCunentZooD ); 



RESULT CODES 



OSBg >fcriryftajmffrtArf)rivgr 

(CorwrlimTP 

NuDi iwdBuliyEV i iiilPu 

DnverDesctTptiGDPtr *duveiDeec); 
frtgnwitCoopID CPM c o o n e ai o u lD 

ftagrnfintMatn racuhing pointer to DoDrivedO 

tkrvciDeec resulting pi*ii<g to ^^^TTTViff i ip^ini 



Given a CFM oonnectionlD value for a code fragment, 
VerifyRragmoitAsDriver verifies that the fragment is a 
driver. It returns a pointer to the driver's DoDriverlO entry 
point in fragmentMain and a pointer to its Driver Descrip- 
tion in driverDesc. 



noBrr 

All CFM errors 



No error 



InstallMverFroinFragment 

InstallDriverrromFragment installs a driver fragment in 
the Unit Table. 



15 



OSEu InatanrVfvwPinnJrBgin^nt 

(Q>nnfrtrmTn 
RegEntrylDPtr 

refNum 



device, 

bcyiiiitii^XJiiiit^ 
*renVum>: 
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Installation 

Once loaded, a driver must be installed in a Unit Table 
(stored in memory) to become available to Device Manager 
clients ("applications"). This process begins with a CFM 
fragment connection ID and results in a refNum. The 
installing software can specify a desired range of unit 
numbers in the Unit Table. For example, SCSI drivers use 
the range 32 to 38 as a convention to their clients. If the 
driver cannot be installed within mat range, an error is 
returned. The Unit Table grows to accommodate the new 
driver as welL 

In one embodiment, the unit table may grow only if the 
unit number is between some defined number (for example 
48) and the current highest unit number as returned by the 
HighestUnitNuntber procedure. When installing a native 
driver, the caller also passes the RegEntrylDPtr of the device 
which the driver is to manage. This pointer (along with the 
refNum) is given to the driver as a parameter in the initial- 
ization command. The driver may use this pointer to iterate 
through a device's property list, as an aid to initialization. 
The native driver should return noBrr to indicate a success- 
ful initialization command. These functions, described in the 
below, operate on a loaded driver fragment: (1) verifyFrag- 
mentAsDriver verifies fragment contents as driver; (2) 
InstallDrrverf^mFr^gTJ^iit places a driver fragment in the 43 
Unit Table; (3) InstallDriverltonDisk places a disk-based 
driver in the Unit Table; and (4) OpenliistalledDriver opens 
a driver that is already installed in the Unit Table 

VerifyHragmentAsDriver so 

VerifynragrnentA&Driver guarantees that there is a driver 
in a given fragment 



fngmeoa&amlD CFM axmectjotfD 

device pointer to Name Registry specincatkm 

beginaiagUait low unit nu mber in Unit Table 

eodingUnit high unit num b ei m Unit Table range 

renVum tentttngUhftlabfere&fam 



25 ListallMverr^mFragrnent installs a driver that is located in 
a CTM code fragment, using the standard code fragment 
search path, anywhere within the specified unit number 
range of the Unit Table. It invokes the driver's Initialize 
conimand, passing the RegEntrylDPtr to it The driver's 
30 initialization code must return noErr for IostallDriverFron> 
Fragment to complete successfully. This function returns the 
driver's refNum but it does not open the driver. If the 
requested Unit Table range is from the determined number 
(e.g., 48) to the highest unit iramber currently available, as 
35 returned by the HighestUnitNumber procedure, and if that 
range is currently filled, the Unit Table will expand to accept 
the new driven If the Device Manager 90 has already 
enlarged the Unit Table to its manimmn possible size, 
however, IhstallDrrveri^mf^agmrat will return unifTbl- 
40 FuDErr. 



RESULT CODES 




0 No error 




badUntflBrx 


—21 Bad unit nmihw 




umOtaToIIBn 


—29 Usxt table or xsqnotftc 


d range roll 


SpftfinV fefuf us ] 


sitiahxef Replace^ ^■n-'-'awlfft 




AH CFM errors 







InstaIlDriverFrom£>isk 

InstallDriverl^xnDisk locates a file in the Extensions 
folder that is in the Mac OS System folder, verifies that the 
55 file's contents are a native driver, and loads and installs the 
driver. 



OSErr InstallDi we ifto uj Diak 

(Ptr ibiiwiName, 
ItegEntryTDPtr device, 

DnverRefNuai *taflfa&i); 
drf^ei^fuije a^uoc of a duafe file o^utfliiiii*y %■ ^Luycy 
device RriDter to cutiy in the Nsdc Registry 

^ bcginniiigUnit First Unit f Ikbk nunibai of zsnge acceptable for 
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endingUmt Last Unit Tabic number of range acceptable for 
installation 

rcfNum Reference number returned by InstallDiiveiFiuiiDist 
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InstaUMverFromFile 

mstallDriverftomHle loads a driver from a file and 
installs it. 



10 



ListallDriverFromDisk installs a driver that is located on 
disk 104 anywhere within the specified unit number range of 
the Unit Table and invokes the driver's Initialize command* 
passing the RegEntrylDPtr to it The driver's initialization 
code must return noErr for InstallDriverFromDisk to com- 
plete successfully. This function returns the driver's refnum 
but it does not open the driver. If the requested Unit Table 
range is from the determined number (e.g., 48) to the highest i$ 
unit number currently available, as returned by the Highes- 
tUnitNurnber procedure, and if that range is currently filled, 
the Unit Table will expand to accept the new driver. If the 
Device Manager 90 has already enlarged the Unit Table to 
its maximum possible size, however, IiistallMvetFromPisk 20 
will return unifThlFullErr. 



RESULT CODES 



noEir 


0 


No error 




fnffixr 


-43 


File not found 




badUmlEn- 


-21 


Bad ii^t number 




uaifTUPuUErr 


-29 


Unit table or requested rac 


«e full 


All CFM errors 
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OSErr IiistalII>riverJ 3 rcrmFile (FSSpecPtr fragrnentSpec, 
RegEatrylDPir device, 
UmtNumber beginningUnit, 
UmtNumber ending Unit, 

rcfNum *refNum); 
fragmentSpec pointer to a file system «p-^fytitinn 
device pointer to Name Registry Specification 

beginningUnit low unit number m Unit Table Range 
endmgUcit high unit number in Unit Table Range 

rcfNum resulting Unit Table refNum 



InstallMverFromFIle installs a driver that is located on disk 
104 anywhere within the specified unit number range of the 
Unit Table and invokes the driver's Initialize command, 
passing the RegEntrylDPtr to it The driver's initialization 
code must return noErr for InstallDriverFromFile to com- 
plete successfully. This function returns the driver' s refNum 
but it does not open the driver. 

If the requested Unit Table range is from the determined 
number (e.g., 48) to the highest unit number currently 
available, as returned by the HighestUnitNumber rrocedurc, 
and if that range is currently filled, the Unit Table will 
expand to accept the new driver. If the Device Manager has 
already enlarged the Unit Table to its maximum possible 
size, however, InstallMverFromHle will return unitTbl- 
FuIlErr. 



OpenInstalledI>river 

OpenlnstalledDriver opens a driver mat is already 
installed in the Unit Table. 35 



OSErr OperdnstalledDriver 

(DnverRefNoni refNum, 
SEnt8 kf e uiuaa ico); 
refNum Unit T&bk reference number 
VOperminoocode: 
fsCurPsrm 0 retain current 
fsRdFerm 1 allow read actione only 
fsWrPexm 2 allow write yt'nw only 
faRdWrfVrm 3 allow both read and write actions 
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Given an installed driver's Unit Table reference nmnber, 
OpenlnstalledDriver opens the driver. The Device Manager 
90 ignores me ioPeniiission parameter, it is mdiwled only to 
provide easy coinmiinicatiou with the driver. 



RESULT CODES 


noErr 


0 


No error 


badUmlErr 


-21 


Bad unit number 


uoxfEniptyErr 


-22 


^"^l^y (Bit i**!uVcr 



55 



RESULT COKES 



noBir 


0 


No error 




mfflrr 




FQe not found 




badUniffiir 


-21 


Bad out ocnxfacr 




imifTUFuIIErr 


-29 


Unit table or requestrx 


1 range full 


All CFM errors 









InstallDrrverFroii^eraoiy 

InstallDriverEramMemory loads a driver from a range of 
memory and installs it 
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OSErr bstallDrrrerBromMemoTy 

(PIT 



50 



fragN« 



endrngUnit 
refNum 



long 

Stx63 fragNaxne, 
RegEntrylDPtr device, 

T htttW i if i Jiwy codlngUnii, 
refNum *refNum); 

An oprinwl name of the fragment 
(primarily uaed by debugger) 
pointer to Name Registry i 



low unit number m Unit Table range 
resulting Unit Table refNum 



Load and Install Option 

Callers wishing to combine the loading and installation 
process in one service may want to use one of the following 
functions, described in the next sections: (1) InstallDrrvex- 
RromRle loads and installs a file-based driver; and (2) 
IiistallDriverFrornMemOTy loads and installs a memory- 
based driver 



60 In staflDriverFromMemory installs a driver that is located 
in a CFM code fragment, using the standard code fragment 
search path, anywhere within the specified unit number 
range of the Unit Table. It invokes the driver's Initialize 
command, passing the RegEntrylDPtr to it The driver's 

65 initialization code must return noErr for InstallDriverRom- 
Memory to complete successfully. This function returns the 
driver's refNum but it does not open the driver. If the 
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requested Unit Table range is from the determined number 
(e.g., 48) to the highest unit number currently available, as 
returned by the HighestUmtNumber procedure, and if that 
range is currently filled, the Unit Table will expand to accept 
the new driver, If the Device Manager has already enlarged 
the Unit Table to its ma ximum possible size, however, 
mstallDnvaFromMemory will return unitTMFullErr. 



RESULT CODES 


no£rr 


0 No 


tadUnKErr 


—21 Bad unit number 


unifTblFullErT 


-29 Unit table or requested range fall 


AD CFM errors 





OSEn InstaIID u»uI\MP cvice 

(iusgEiitrylDPtr device, 

UnfrNumbcr begnxoingUnaV 

T T y] it Wran^wr cudmgUnjt, 

refNum tetKam); 
device pointer to Name Registry specification 

bfignmngUnit tow unit m mW m Unit latie rage 

eodxngUiiit high unit n""*"* in Unit Table range 

feflfam resuttmg Unit Table refrfam 



InstallDrrvcrForDevice finds, loads, and installs the best 
driver for a device identified by its RegEntrylD value. In one 
embodiment, it installs the driver anywhere within the 
specified unit number range of the Unit Table and invokes its 
Tmrii>K7i» command, passing the RegEntrylDPtr to it The 
driver's inidalization code most return noErr for InstaDD- 
riverForDevice to complete successfully. This function 
returns the driver's refNum but it does not open the driver. 
If the requested Unit Table range is from the determined 
number (e.g., 48) to the highest unit number currently 
available, as returned by the Hig^estUnitNumber procedure, 
and if that range is currently filled, the Unit Table will 
expand to accept the new driver. If the Device Manager 9# 
has already enlarged the Unit Table to its maximum possible 
size, however, InstallOriverForDevice will return unifTbl- 
FulIEzr. 



RESULT CODES 



ooBrr 

mfBrr 

badUnilEn 



0 
-43 
-21 



No error 
File not found 
Bad u 
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RESULT CODES 



unyrMFuitHiT 
AU CTM errors 



-29 Unit table or requested range full 
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HigherDriverVersion 

Higher DriverVersion compares two driver version 
numbers, normally the values in their DriverDescription 
structures. It returns a value that indicates which driver is 
later. This service may be used by any software that loads or 
evaluates drivers. 
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Match, Load and Install 

Those wishing to combine the matching of the best driver 
for a device, with the loading and installation process in one 20 
service, may use InstallOriverForDevice and 
HigherDriverVersion, described in this section. The Driver- 
Description data structure is used to compare a driver's 
functionality with a device's needs as discussed above. Hie 
Driver Loader Library picks the best driver for the device by 25 
looking for drivers in the Extensions folder (device driver 
folder) and comparing those against drivers in the device's 
property list 

InstallDriverForDevice 30 

InstallDrivcrForDevice installs the "best" driver for a 
device. The procedure for detennining the best driver is 
described in FIG. 11. 



short H«gherl)rjver\ferston (Num\fcraiOD *V1, Num vennon *V2); 

struct NumVteraioo { 

Umt8 mtjcrRev; /*lst part of version number in BCD*/ 

Umt8 minor AndBugRev; /*2nd sod 3rd part of version number 
share a byte*/ 

Umt8 stage; /*stage code: dev, alpha, beta, final*/ 

Umt8 dooRbIKcy; f*rw level of noD-xcleaeed version*/ 



VI 
V2 



Rrst version number being compared 
S^TTtH version number being c om pared 



HigherDriverVersion returns 0 if vl and v2 are equal It 
returns a negative number if V1<V2 and a positive number 
greater than 0 if V1>VZ If both drivers have stage values of 
final, a nonReJRev value of 0 is evaluated as greater man any 
nonzero number. 

Stage codes are the following: 
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devetopStage =0x20 

ifrhaStagp = 0x40 

betaStage =0x60 

finalStage =0x80 
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Driver Removal 

Applications wishing to remove an installed driver can 
use RemoveDriver, see Week 240 of FIG. 7. 



RemoveDriver 
45 RemoveDriver removes an installed driver. 

RcnovcDnver 



50 



refNum 



(refNum tsfNuui* 
Boolean n^omedKats^v 
refNom of driver to remove 
true means doo'1 wait Cor driver to become idle 
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RemoveDriver accepts a refNum and unloads a code frag- 
ment driver from the Unit Table. It invokes the driver's 
Finalize oommand. If called as immediate, it does not wait 
for driver to become inactive. 



JtBSUETCOCSS 




0 


No error 


badXJnifErr 


-21 


Bad out number 




-22 


B^Dpty/ unit number 
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Getting Driver Information 

Applications wishing to acquire information about an 
installed driver can use GetWverlnformarion. 



01/20/2003, EAST version: 1.03.0002 



5,802,365 



37 

GetDriverlnformation 



GetDriverlnforniation returns a number of pieces of infor- 
mation about an installed driver, see block 220 of FIG. 7. 



OSErr GetDrrvCTlnfotmaticG 
(DriverRefNum 
UnitNumber 
DrivexFlags 
DrrverOpenCount 
StnngPtr 
RegEntrylD 
CFragHFSLocator 
CFragConnect kanlD 
Driver£inryPointPtr 
DriverDescriptiao 
refNum 



refNum, 
*unitNum, 
•flags, 
•count, 



arireiLocation 

frsgmentMani 
dnvctPcac 



•device, 

•drivrrf oarif rfyBtton, 
* fragmentCoualD, 
♦fragmentMain, 
♦drrverDeac); 
refNum of driver to examine 

resulting DCE flag bits 

number of times driver has been opened 

resulting driver name 

resulting Name Registry device specification 
resulting CFM fragment locator 
(from which tbe driver was loaded) 
resulting CFM connection ID 
resulting pointer to DoDrivcrlO 
resulting pointer to DttvctDbsc ri pt jod 
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Given the Unit Table reference number of an installed driver, 
GetDnvcrlnfonnation returns tbe driver's unit number in 
unit, its DCE flags in flags, tbe number of times it has been 
opened in count, its name in name, its RegBntrylD value in 
device, its CFM fragment locator in driverLocation, its CFM 
connection ID in&agmentConnlD, its DoDriverlO entry 
point in rragmentMain, and its Driver Description in driver- 
Desc 



RESULT CODES 


iriRir 


0 


No ecror 


badUmfBrr 


-21 


Bad unit number 




-22 


£oopty imu£ umber 
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Searching For Drivers 



10 
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The exemplary procedures described in this section help 
clients iterate through the Unit Table, locating installed 
drivers. 

HighestUnitNumber 

HighestUnitNumber returns the currently highest valid 
unit number in the Unit Table. UnitNumber HighestUnit- 
Number (void); 

HighestUnitNumber takes no parameters. It returns a Unit- 
Number value that represents the highest unit number in the 
Unit Table. 

LookupDrivers 

LookupDrivers is used to iterate through the contents of 
the Unit Table. 



LoofamDrras (UnitNumber 
UmtNumber 



endingUoit 
25 enmtyUnits 



DriverRefNum 
Pint unit in range of units to 
Last unit in range of units to i 
true: return available units 
filing tctum allrw aSftd 



begintiingUnit, 
endmgTJmtf 
empty Units, 
^FftftirrtftdK iff fNiiik 
•refNums); 



rftprfti totum aiirff aiftfi umia- 

ly^y nyytP #t IWim ta firyiim number of fCfeVBDOO 



refNums 
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rtft||ijilwfK^gi t oooCams actual 
returned 

resulting array of returned refNums 



numbers to return; oa 
of lefNums 



Given the first and last unit numbers to scan, LookupDrivers 
returns the reference numbers of both native and 6SK 
drivers. The emptyUnits parameter tells it to return either 
available or allocated units andretumedRefNunis tells it the 
maximum number of reference numbers to return. When 
LookupDrivers finishes, irturnedRefNums contains the 
actual number of refNums returned. The sample code shown 
below uses HighestUnitNumber and LookupDrivers to print 
out the reference numbers of all installed drivers and obtain 
driver information. 



RESULT CODES 

noErr 0 No < 

paramBrr -50 Bad ( 

fadAHDriven ( ) 

{ 

UmtNumber tneUnit & O; 
DrrmftafNum theRefNum, •ruOSiaedRenVumBufav; 
// Method #1: Iterate with a amaU output buffer 
white ( (tbeVmt <= H5gfcesrUnitNim*er( ) ) && 

(lxx>kupDrh^tl»Unit, theUnit, talae, AmeCount, &theRofNum) — n oErr) ) 

{ 

if (meCouot = l)printf ( "Refc«im;#%d is allocated. \n** f tbeRefNum); 

tneOount = 1; 

theUmt++; 

> 

// Method #2; Get all refnums wxm one call 
mllSiiedReftJuniBufler = NewPtr ((HignerfUiiitNumber{ ) + 1)* 

atzeon^DrivBrRsfNum)); 
meCount = (ffigheatUmuHuoiberX ) + 1); 

LoofaipDrivers (0, HxgheatUnhlCumberf X falae, fttoCount, fii n R f w ^* rfw t""^ff ffFr); 
£br(tfaeUnit=O^Unit <^ieCoant^UmfM-) 

{ 

prmrfT^ irfrtnm #%d is al Vm t H VrT, faiisH™rtB *fi fi™ifaifw [theUmtj); 
ShcwDriverinfo (fallSttedRefNumBuf&r [tbeUnit]); 

} 

DisposePu<n^aedRenVuiiiBuffiBr): 
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-continued 



} 

ShowDriverinfb (DriverReftftm *»fNum) 
{ 

UnitNianber thcUnit; 

DriverRcfNum aRefNiMn; 

DriverFlags theFlags; 

FSSpec (frivaPileSpec; 

RegEnlrvID tfeDevioe; 

CFragHFSLocatot theLoc; 

SH255 tbeName; 

CFragCoDnectiooID fr ^^irwiqi p- 

DnxerOpcoOouol tfacOpeaOount 

DriwrDeacriptxHi theDnveiDesciiptksi; 
dieLoGkupoQDtsk^JeSpec = ftdrmsFifeSpec; 
OetDnverinformsticD ( aRdNum, 
ftthcUiiit, 

&tttfOpaiCount, theName, 

fttbADevice, 

&tbcLoc, 



&tbeDnvex0escnptioii); 
printf ("Driver's fiagf are: fciNiT, tbeFUgs); 



Finding, Initializing, and Replacing Drivers 

The native driver framework tolerate a wide range of 
variations in system configuration. Although drivers and 
expansion cards may be designed and updated 
independently, the system autcconfigurafion firmware offers 
several techniques for making them work together. This 
section discusses what PCI driver and card designers can do 
to improve the compatibility of their products. 

Device IVoperties 

A PCI device is required to provide a set of properties in 
its Pd configuration space. These properties can be used in 
the device tree It database for a particular device. It may 
optionally supply FCode and runtime driver code in its 
expansion ROM. PCI devices without FCode and runtime 
driver code in ROM may not be used during system startup. 
The required device properties in PCI configuration space 
are: (1) vendor-ID; (2) device-ID; (3) class-code; and (4) 
revision-number. For PCI boot devices there must be an 
additional property: driver-reg, AAPL, MacOS, PowerPC 
This property contains a pointer to die boot driver's image 
in the PCI card's expansion ROM. It is used in conjunction 
with the f code-roxn-of f set p roperty. The OpenFirmwarc 
FCode in a PCX device's expansion ROM (eg., ROM 1*3) 
must provide and install a driver-reg property, as shown 
above, to have its driver appear in the Name Registry and be 
useful to the system during startup. It must also add its 
expansion ROM's base register to the reg property, so that 
system firmware can allocate address space when instiling 
the driver. 

Boot Sequence 

The following is a short description of a boot sequence 
(e.g., for PCI standard): 1. Hardware reset 2. Open Firm- 
ware creates the device tree. This device tree is composed of 
all the devices found by the Open Firmware code including 
all properties associated with those devices. 3. The Name 
Registry device tree is created by copying the Macintosb- 
relevant nodes and properties from the Open Firmware 
device tree. 4. The Code Fragment Manager and the Inter- 
rupt Tree are imrinhzftd 5. Device properties that arc per- 
sistant across system startups and are located in NVRAM 



25 are restored to their proper location in the Name Registry 
device tree. 6. The Name Registry device tree is searched far 
PCI expansion ROM device drivers associated with device 
nodes. 7. PCI expansion ROM device drivers required for 
booting are loaded and initialized. 8. If a PCI ROM device 

30 driver is marked as kdmerIsIx>adedUrx)mOiscovery, the 
driver is installed in the Device Manager Unit Table. 9. If a 
PCI ROM device driver is marked as 
lotoverlsOpenedUrxmLoad, the driver is initialized and 
opened, and the driver-ref property is created for the driver's 

35 device node. 10. The Display Manager is irritated. 11. The 
SCSI Manager is initiated 12. Tbe Hie Manager and 
Resource Manager are initialized. 13. Device properties that 
are persistent across system startups and located in the folder 
System Folder: Preferences are restored to their proper 

40 location in the Name Registry device tree. 

Device drivers that fall under Family Expert control are 
processed next The following steps load disk-based experts 
and disk-based drivers: 1. Scan the extensions folder for 
drivers, (file type "ndrv'), updating the Registry with new 

45 versions of drivers as appropriate. For each driver added ox 
updated in the tree, a driver-description property is added or 
updated as well. 2. For each driver that is replaced, and 
already open, use the driver replacement mechanism. 3. Ron 
'imV resources for virtual devices. 4. Scan the extensions 

50 folder for experts, (file type 'cxpt'); load, initialize, and run 
the expert 5. Run experts to scan the registry, using the 
driver-description property associated with each node to 
determine which devices are of the appropriate family. 6. 
Load and initialire appropriate devices based on family 

35 characteristics. At that point all devices in use by the system 
and family subsystems are iw'riflH^H Uninitialized and 
unopened devices or services that may be used by client 
applications are located, initializrd, and opened at the time 
that a client makes a request for the devices or services. 

60 

Matching Drivers With Devices 

The matching logic of the present invention is presented 
above with respect to FIG. 8 FIG. II. In one exemplary 
embodiment, the DLL 45 procedures GetDriverForDevice, 
65 IiistallMverForDcvice, and HndDrrversForDevice use the 
following procedure to match or install the "best** driver for 
a device under the present invention: 1. Find all candidate 
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DeviceProbe (veil *te&c, 




void •thcDcst, 


theSic 


UInt32 Acceaafiype); 


The address of the device lo be accessed 


tbeDest 


The destination cf the contents of theSrc 


Acceasiype 


How theSxc is lo be aoceased: 




kSBitAeceas 




klcBttAccess, 




U2BitAoceas 
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drivers for the device to build a candidate list A driver 80 clients have issued close requests. Initialization can occur 
is a candidate if its namelnfoStr value 80c matches either the independently of client requests; for example at startup time, 
device's name 50 or one of the names 60a found in the or (in the case of PCMCIA devices), when a device is 
device's compatible property. 2. Sort this list based on hot-swapped into or out of the system. Initialization of 
whether the driver 80 matched using the device* s name 50 5 native device driver controlled devices is handled in phases 
or a compatible name 60a. Those matched with the device as described in the previous section, lit is necessary to make 
name 50 are put at the head of the candidate list Tie are a distinction here between PCI drivers and 68K drivers 
broke using the driver's version number information. 3. If because the 68K driver initialization path has not changed 
not installing the driver, return the driver at the head of the u one embodiment, the first phase of native driver 
candidate list and go to step 7 below. 4. While mere are 10 initialization consists of searching the device portion of the 
candidates with which .to attempt an installation, do the Name Registry looking for boot devices. Boot device nodes 
foUowiBgster*^ should be flagged as kdriverlsppenedUponLoad in the 

head of the candidate list 6. The driver should probe the MverDescriptor property associated with the device node, 
device, using DSL services, to verify the match, ff the driver These devices are loaded, initialized, and opened by the 
did not successfully mibalize itself report error. 7. Discard 15 system. These drivers must be in ROM 103 and must be of 
any remaining candidates. service category 'ndrv'. Drivers should be passive code 

TV- • PmKp controlled by a client — in this case, the system starting up. 

uevicewooe Pa bridges are tagged kMverbLc^dedUrx>riDiscovery and 

DeviceProbe is used to determine if a hardware device is kMverlsC^enedUponLoad. 
present at the indicated address. This process can operate 20 In one embodiment, the second phase of startup comes 
during block 530 of FIG. U. after the file system is available, In this second phase the 

device driver folder (eg., extensions folder) is scanned for 
Family Experts, which are run as they are located. Their job 
is to locate and initialize all devices of their particular 
service category in the Name Registry 10. The Family 
experts are imrinHmH and run before their service category 
devices are initialized because the Family expert extends the 
system facilities to provide services to their service category 
devices. For example, the DisplayManager extends the 
system to provide VBL capabilities to 'disp'service category 
drivers. In the past, VBL services have been provided by the 
DeviceProbe accesses the indicated address and stores the Sk * M "^™ withaative ^V* 3 ' family-specific ser- 
contents at thcDcst using AccessType to determine whether SL^tS . ^? f**^ * ° f 

it should be an 8-bit l£bit or 32-bit access. Upon success 35 * ^ a « f ^ Softwarc - 

it returns noErr. If the device is not present, e.g., if a bus Driver Replacement 

error or a machine check is generated, it returns noHardwa- 

reErx If a device such as a PCI card contains no FCode, and This section describes the mechanism to allow update of 
therefore is assigned a generic name of the form pdxxxx, * ROM-based driver with an newer disk-based version, 
yyyy, it is important for a driver to provide diagnostic code 40 After the Registry is populated with device nodes, the 
in its Initialize procedure. When a driver is matched with a startup sequence initializes the devices. For every device 
card that has a generic name property, it may be the wrong no ^ e m tne Registry there are two questions that require 
driver. In that case, diagnostic code probing for a unique answers before the system can complete a client request to 
characteristic of the card may not only fail a data compare, ^ device. The client may be the system itself or an 
but can cause a possible unrecoverable machine check 45 application. The questions are: (1) Is there a driver for this 
exception. DeviceProbe allows a driver to explore its hard- node? (2) Where is the most current version of the driver for 
ware in a recoverable manner. It provides a safe read ***** node? 

operation, which can gracefully recover from a machine If there is a driver in ROM 103 for a device, the driver, 
check and return an error to the caller. If DeviceProbe fails, AAPL, MacOS, PowerPC property is available in the Name 
the driver should return an error from its Initialize command, so Registry 10 whenever a client request is made to use that 
This return may cause the DLL 45 to continue its driver-to- device. However, after the operating system is running and 
device matching process until a suitable driver is found. the file system is available, the ROM driver may not be the 

driver of choice, In this case, the ROM-based driver is 

— — — — replaced with a newer version of the driver on disk. In the 

rasuu codes 55 system startup sequence, as soon as the file system 104 is 

o Device pram available the operating system 30 searches the device driver 

ooHordwareExr Device not peso* folder (e.g., Extensions folder) and matches drivers in that 

— — — —> — — — _ folder with device nodes in the Name Registry. The drfver- 

InfoStr and version fields of the DriverTtype field of the two 
Opening Devices 60 DriverDescriptors 80a are compared, and the newer version 

of the driver is installed in the tree. When the driver is 
There is a distinction between device initialization and updated, the DriverDescriptor property and all other prop- 
device opening. A device opening action is a connection- erties associated with the node whose names begin with 
oriented response to client requests Device drivers should Driver are updated in the Name Registry 10. 
expect to run with multiple Open and Qosecomniands. This 65 If the driver associated with a node is open (that is, if it 
means that each driver is responsible for counting open was used in the system startup sequence) and if the driver is 
requests from clients, and must not close itself until all to be replaced, the system must first dose the open driver, 
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using the driver-ref property in the Name Registry 10 to 
locate it The system must then update the Registry and 
reinstall and reopen the driver. If the close or finalize action 
fails, the driver will not be replaced. The native driver model 
does not provide automatic replacement of 68K drivers (type 
'DRVR'). If an application needs to replace a 68K driver 
with a native driver dynamically, the open 68K driver is 
closed and its state information is extracted, and load and 
install the native driver using the Driver Loader Library. The 
native driver will occupy the same DCE slot as the 68K 
driver and use the same refNum. After being opened, it will 
start running with the state information that was extracted 
from the 68K driver. 

Applications and other software can use the ReplaceDriv- 
erWithFragment function to replace one driver with another 
and RenameDriver to change a driver's name. These pro- 
cedures are described next 

ReplaceDriverWitriFragrnent 

ReplaceDriverWithFragment replaces a driver mat is 
already installed with a new driver contained in a GFM 
fragment It sends replace and superseded calls to the 
drivers. 



OSEu RepfexDrivexWitfaFraginoat (DriverRrfNum theftefNum. 

CcnoflctiooID fragmaxtCoooID); 
tteJlefNum Reference number of the driver to be replaced 

fragment CoxmED CFM coonectioo IB for the new driver fragment 
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Given the Unit Table reference number of an installed driver 
in theRefNum, ReplaceDriverWimFragment replaces that 
driver with a new driver contained in a CFM fragment 
identified by fxagmentConnlD. It sends replace and super- 
seded calls to both drivers. 
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RESULT CODES 


ooBir 

All CFM em 


0 No error 

ocs 
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RenameE)river 




RenameDriver ct 


umges the name of a driver. 


45 


OSExr ReomeDr 


ivex (DrivvrSeflfum tfaeRefifocD, 




tfaoRetNum Kei 

DKDD W 


StnxjgPtr niimvjj 
farence rrnmhrrr of tbe driver to be win mod 
iufcr to tfao driver's new qhdb 


50 



Given the Unit Tame reference number of an installed driver 
in theRefNum, RenameDriver changes the driver's name to 
the contents of a string pointed to by name. 
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RESULT CODES 



bedUralRrT 



0 
-21 
-22 



No en 
Bad a 



60 



While the present invention has been described in par- 
ticular embodiments, it should be appreciated that the 
present invention should not be construed as limited by such 
anbodiments, but rather construed according to the below 
claims. 
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What is claimed is: 

1. In a computer system having a processor coupled to a 
communication bus, a memory unit coupled to said com- 
munication bus, and devices coupled to said communication 
bus, a method for configuring a particular device of said 
devices with a device driver, said method comprising the 
computer implemented steps of: 

reporting a device name associated with said particular 
device; 

scanning a first set of available drivers within said com- 
puter system to determine a second set of drivers 
individually having a driver name that matches with 
said device name; 

for each individual driver of the second set of drivers, 
scanning a first set of families available within the 
computer system to determine a second set of families 
comprising at least one family, each family of the 
second set of families having category information 
which matches category information associated with 
the individual driver of the second set of drivers; 

installing at least one family of the second set of families; 

sequentially ^ttrmp Hn g installation of individual drivers 
of said second set of driven with said particular device 
to determine a matching driver of said second set of 
drivers mat properly configures said particular device; 
and 

reporting said matching driver of said set of drivers that 
property configures said particular device upon an 
indication by said step of sequentially attempting 
installation. 

2. A method as described in claim 1 fm^herconnwisingthe 
computer implemented step of sorting said second set of 
drivers and families by a priority of compatibility with said 
particular device and wherein said step of sorting comprises 
the further computer innplemented steps of: 

sorting said second set of drivers such that an mdrvidual 
driver matching with said device name is given higher 
priority over an individual driver rnatching with at least 
one compatible device name which is associated with 
said particular device; and 

sorting said second set of drivers according to driver 
version information; and 

selecting a family having a highest version number of the 
fanuHes of the second set of families. 

3. A method as described in claim 1 wherein said step of 
sequentially attempting installation comprises the computer 
implemented steps of: 

probing said particular device with a particular driver of 

said second set of drivers; 
performing a diagnostic test with respect to said particular 

driver and said particular device; and 
reporting a status indicating whether or not said particular 

driver and said particular device are compatible. 

4. A method as in claim 1 wherein said report- 
ing comprises the computer implemented steps of: 

accessing informatioa derived from a device tree database 
containing information regarding said devices of said 
computer system; 

selecting said particular device from among said devices; 
and 

accessing said device name and said at least one compat- 
ible device name associated with said particular device 
from said information derived from said device tree 
database. 
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5. A method as described in claim 1 further comprising the 
computer implemented step of installing said matching 
driver with said particular device provided resources are 
available within said computer system required for operation 
of said particular device. 

6. A method as described in claim 1 further comprising the 
computer implemented steps of: 

scanning a third set of available drivers within said 
computer system to determine a fourth set of drivers 
individually having a driver name that matches with 
said device name, said third set being more current over 
said first set of available drivers; and 

for each individual driver of the fourth set of drivers, 
scanning the first set of families available within the 
computer system to determine a third set of families 
comprising at least one family, each family of the third 
set of families having category information which 
matches category information associated with the indi- 
vidual driver of the fourth set of drivers. 

7. A method as described in claim 6 further comprising the 20 
computer implemented steps of: 

sequentially attempting installation of individual drivers 
of said fourth set of drivers and said third set of families 
with said particular device to determine another match- 
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10. A method as described in claim 9 wherein said step of 
sorting said second set of drivers by a priority of compat- 
ibility with said particular device comprises the further 
computer implemented steps of: 

sorting said second set of drivers such that an individual 
driver matching with said device name is given higher 
priority over an individual driver matching with a 
compatible device name of said set of compatible 
device names; 

sorting said second set of drivers according to driver 

version information; and 
selecting a family having a highest version number of the 

families of the second set of families. 

11. A method as described in claim 8 wherein said step of 
sequentially attempting installation comprises the computer 
implemented steps of: 

probing said particular device with a particular driver of 

said second set of drivers; 
performing a diagnostic test with respect to said particular 

driver and said particular device; and 
reporting a status indicating whether or not said particular 

driver and said particular device are compatible. 

12. A method as described in claim 9 wherein said step of 



ing driver of said fourth set of drivers that property 25 reporting comprises the further computer implemented steps 



configures said particular device, said another matching 
driver being more compatible with said device com- 
pared to said matching driver, and 
reporting said another matching driver upon an indication 
by said step of sequentially attempting installation of 
individual drivers of said forth set of drivers. 

8. In a computer system having a processor coupled to a 
communication bus, a memory unit coupled to said com- 
munication bus, and devices coupled to said ccminunication 
bus, a method for configuring a particular device of said 
devices, said method comprising the computer implemented 
steps of: 

reporting a set of device names associated with said 
particular device; 

scanning a first set of available drivers within said com- 
puter system to determine a second set of drivers 
individually having a driver name mat matches with 
any name of said set of device names; 

for each individual driver of the second set of drivers, 
scanning a first set of families available within the 
computer system to determine a second set of families 
comprising at least one family, each family of the 
second set of families having category information 
which matches category information associated with 
the individual driver of the second set of drivers; 

sorting said second set of drivers by a priority of com- 
patibility with said particular device; 

installing at least one family of the second set of families; 

sequentially attempting installation of individual drivers 
of said second set of drivers with said particular device 
to determine a first matching driver of said second set 
of drivers that properly configures said particular 
device; and 

installing said first matching driver with said particular go 
device upon an indication by said step of sequentially 
attempting installation. 

9. A method as described in claim 8 wherein said a set of 
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of: 

accessing information derived from a device tree database 
containing information regarding said devices of said 
computer system; 

selecting said particular device from among said devices; 
and 

accessing said device name and said set of compatible 
device names associated with said particular device 
from said information derived from said device tree 
database. 

13. A method as described in claim 8 further wherein said 
step of installing said first matching driver comprises the 
further computer implemented steps of: 

determining that said computer system contains resources 
required by said particular device for proper operation; 
and 

installing said first matching driver with said particular 
device provided said resources required by said par- 
ticular device are present within said computer system. 

14. A method as described in claim 9 further comprising 
the computer implemented steps of: 

scanning a third set of available drivers within said 
computer system to determine a fourth set of drivers 
individually having a driver name that matches with 
either said device name or any name of said set of 
compatible device names, said forth set larger than said 
second set; 

sorting said fourth set of drivers by a priority of compat- 
ibility with said particular device; and 

for each individual driver of the fourth set of drivers, 
scanning the first set of families available within the 
computer system to determine a third set of families 
comprising at least one family, each family of the third 
set of families having category information which 
matches category information associated with the indi- 
vidual driver of the fourth set of drivers. 

15. A method as described in claim 14 further comprising 



device names associated with said particular device com- 
prises a device name of said particular device and a set of 65 *e computer implemented steps of: 
compatible device names indicating devices compatible sequentially attempting installation of individual drivers 
with said particular device. of said forth set of drivers with said particular device to 
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determine a second matching driver of said forth set of 
drivers that properly configures said particular device, 
said second matching driver being more compatible 
with said device over said first matching driver; 
removing said first matching driver from said particular 
device; and 

installing said second matching driver with said particular 
device. 

16. A computer readable medium storing instructions for 
a digital processing system having a processor coupled to a 
bus and a particular device coupled to said bus, wherein 
when said instructions are executed by said processor, said 
system is caused to perform the steps of: 

reporting a device name associate with said particular 
device; 

scanning a first set of available drivers within said system 
to determine a second set of drivers individually having 
a driver name that matches with said device name; 

for each individual driver of the second set of drivers, 
scanning a first set of families available within the 
system to determine a second set of families compris- 
ing at least one family, each family of the second set of 
families having category information which matches 
category information associated with the individual 
driver of the second set of drivers; 

installing at least one family of the second set of families; 

sequentially attempting installation of mdfvidual drivers 
of said second set of drivers with said particular device 
to determine a matching driver that properly configures 
said particular device; and 

reporting said ™trhfwg driver of said set of drivers that 
properly configures said particular device upon an 
indication by said step of sequentially attempting 
installation. 

17. A computer readable m^tinm as in claim 16 wherein 
when said instructions are executed, said system is caused to 
perform the further step of: 

sorting said second set of drivers and families by apriority +q 
of compatibility with said particular device and 
wherein said step of sorting comprises: 
sorting said second set of drivers such mat an indi- 
vidual driver matching with said device name is 
given higher priority over an individual driver 45 
matching with at least one compatible device name 
which is associated with said particular device; and 
sorting said second set of drivers according to driver 

version information; and 
selecting a family having a highest version number of 
the families of the second set of families. 

18. A computer readable mndiiim as in claim 16 wherein 
said step of sequentially ^*irq*jng installation comprises 
the steps of: 
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probing said particular device with a particular driver of 

said second set of drivers; 
perf orming a diagnostic test with respect to said particular 

driver and said particular device; and 
reporting a status indicating whether or not said particular 

driver and said particular device are compatible. 

19. A computer readable medium as in claim 16 wherein 
said step of reporting comprises: 

accessing information derived from a device tree database 
containing information regarding said devices of said 
computer system; 

selecting said particular device from among said devices; 
and 

accessing said device name and said at least one compat- 
ible device name associated with said particular device 
from said information derived from said device tree 
database. 

20. A computer readable m^nm as in claim 16 wherein 
said computer readable medium comprises at least one of 
RAM, ROM and a disk drive. 

21. A digital processing system comprising: 
a bus; 

a processor coupled to said bus; 

a particular device coupled to said bus; 

a memory coupled to said bus, said memory storing a first 
set of drivers and storing a first set of families, said 
processor scanning said first set of drivers to determine 
a second set of drivers comprising at least one driver 
that has a driver name that matches a device nany* 
associated with said particular device, said processor 
scanning said first set of families to determine a second 
set of families comprising at least one family having a 
category information which matches category informa- 
tion associated with said one driver, said processor 
irwtqTiing said at least one family and attempting instal- 
lation of said at least one driver with said particular 
device to determine a matching driver mat properly 
configures said particular device. 

22. A digital processing system as in claim 21 wherein 
said processor sorts said second set of drivers and families 
by a priority of compatibility with said particular device 
such that an individual driver i—mting with said device 
name is given higher priority over an individual driver 
matrhing with at leastonc compatible device name which is 
associated with said particular device; 

and wherein said processor sorts said second set of drivers 
according to driver version information and selects a 
family having a highest version number of the families 
of the second set of families. 
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